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

⭐️ 14-16 августа Certified OKR Practitioner (C-OKRP®)
Учим выстраивать целеполагание в организации.

⭐️ 22-23 августа Professional Scrum Master
Разбираем базовый Scrum и работу Скрам-мастера.

⭐️ 22-23 августа Professional Scrum Master Advanced
Углубляемся в работу Скрам-мастера, учимся работать с организацией целиком.

⭐️ 28-30 августа Designing Agile Organizations
Разбираем, как трансформировать компанию в гибкую организацию.

Обучение на осень уже можно забронировать на нашем сайте.

Все онлайн, можно участвовать из любой точки мира! ❤️

⚡️ Даем скидку при покупке двух тренингов.

Читать полностью…

Опыт ВкусВилл. Продолжение.

4️⃣Мощные ИТ-решения.
Стремительный рост розничной сети был бы невозможен без мощной и удобной ИТ-системы. Как и многие другие компании, ВкусВилл разработали свою ИТ-систему с нуля.
ИТ-система - это упрощение и освобождение людей от рутинных, бессмысленных задач, чтобы они могли потратить время на творческие и инновационные. Например, с помощью этой системы сотрудники магазинов отслеживают многие показатели своей работы (например, продажи, количество клиентов и т. д.) в режиме реального времени и могут напрямую вносить изменения и исправления в базу данных товаров компании. Они также могут отслеживать результаты работы в сравнении с другими магазинами, создавая таким образом культуру прозрачности.

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

5️⃣ Деловой ритм.
Работа в ВкусВилл и ее постоянное совершенствование осуществляется в соответствии с четким деловым ритмом, ориентированным на то, чтобы слушать, учиться и действовать в соответствии с отзывами клиентов. Этот ритм поддерживается двумя еженедельными встречами: по понедельникам и вторникам.

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

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

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

6️⃣Ценность ошибок
Одна из главных сильных сторон ВкусВилл - бросать вызов статус-кво с помощью культуры инноваций. Этому способствует то, что ошибки не наказываются, а ценятся. В компании создана культура, в которой люди признают ошибки, а затем анализируют, что именно пошло не так. Они стараются рассматривать ошибки как опыт обучения. Это мотивирует людей пробовать новое и экспериментировать, чтобы повысить ценность для клиентов.

"А что, если ошибка произошла не по злому умыслу, а сотрудник оступился или ошибся случайно? Представьте себя на их месте. Вы любите и цените свою компанию. Но вдруг вы спотыкаетесь или принимаете неверное решение, и компания наказывает вас штрафом. Что вы чувствуете в этот момент? Сильную демотивацию и отсутствие желания вообще что-либо решать".

Вместо этого они пытаются разобраться в причинах ошибок.

"Мы пытаемся понять причину. Были ли это намеренные действия? Или в системе есть ошибка, которая позволила им принять неверное решение? Если виновата система, мы ее меняем. Если налицо явный умысел сотрудника, мы его увольняем".

Прочитать полную версию статьи можно по ссылке.

ВкусВилл, вы огонь.❤️

P.S. А кто-то из наших подписчиков работает во ВкусВилл? Поделитесь в комментариях, у вас всё по-прежнему так?

Читать полностью…

"Я написал нужный код и он работает у меня - давайте выпускать! Что может пойти не так?"

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

Одной из ключевых ценностей экстремального программирования является обратная связь (feedback). Без нее мы не можем быть уверены, что движемся в правильном направлении и что наш продукт работает корректно. Эта ценность реализуется через практику регулярных циклов обратной связи: от сборки и тестирования ПО во всех возможных средах, включая боевые.

Циклы обратной связи в экстремальном программировании (XP):
1️⃣ Совместная работа: Работа в паре, мобе способствует немедленной обратной связи от коллег, улучшая качество кода и обмен знаниями.
2️⃣ Автоматическая сборка (Auto Build): Автоматизация процесса сборки снижает риск и позволяет быстро обнаруживать ошибки, если приложение не собирается, то мы быстро это увидим и сможем исправить ошибку.
3️⃣ Тестирование и тесты:
🔘 Модульное тестирование (unit testing): Написание тестов для каждого отдельного модуля позволяет убедиться, что логика работы модуля работает как мы задумывали.
🔘 Приемочное тестирование (acceptance testing): Проверка того, что программное обеспечение соответствует требованиям к продукту и удовлетворяет ожидания пользователя.
4️⃣ Непрерывная интеграция: Частая интеграция кода в общую ветку (несколько раз в день) позволяет быстро обнаруживать и исправлять ошибки, которые могут возникнуть при слиянии результатов работы нескольких человек.
5️⃣ Непрерывная поставка: Автоматизация процесса поставки программного обеспечения и встроенные в этот процесс проверки, обеспечивает возможность обнаруживать и исправлять проблемы поставки продукта в боевую среду.

⚡️ На нашем тренинге "Applying Software Development for Software Development" студенты уже в первом спринте сталкиваются с вопросом поставки качественного ПО. Они изучают практики экстремального программирования и DevOps, чтобы поставлять качественный продукт каждый спринт или даже чаще.
📎 Ближайший тренинг состоится в сентябре.
🔜 Успейте забронировать себе место!

Читать полностью…

Как структурировать гибкую организацию

Большинство организаций структурируют себя с помощью функциональных направлений: СЕО, под ним VP департаментов, под ними департаменты (маркетинг, продажи, закупки, риски, IT и т.д.).
И это ок!
Вот только если у вас нет цели стать быстрой, адаптивной организацией.

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

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

⚡️ Организации, которые стремятся к адаптивности и скорости, создают продуктовые группы — кросс-функциональные подразделения с PnL (profits & loss) ответственностью, которые возглавляют Владельцы Продуктов.

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

Например, если ваша организация занимается созданием мебели, в продуктовую группу должны войти все функции, необходимые для создания, продажи и поставки “дивана” клиенту:
🔘 Оффлайн продажи (розница)
🔘 Онлайн продажи (e-commerce)
🔘 Дизайн
🔘 Маркетинг
🔘 Конструкторы мебели
🔘 Обучение
🔘 Служба качества
🔘 Логистика

🟡Часть функций, которые прямо не влияют на создание продукта, может быть общей - например, HR, Финансы и т.п.

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

Хотите узнать больше о том, как создавать адаптивные организации и проектировать продуктовые группы?
🔜 Приходите к нам на тренинг Designing Agile Organizations (DAO).
📌 Ближайшая группа 28-30 августа.
⭐️ Регистрация на нашем сайте.

Читать полностью…

8 шагов гембы

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

Митикадзу Танака, ученик Тайити Оно

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

⭐️ Мы можем найти сильные стороны и области улучшения вашей организации
🔜 Запишитесь на консультацию

Читать полностью…

⚡️ Срочно в номер! ⚡️
По всему миру глобальные сбои. Не работают аэропорты, авиалинии, банки, платежные системы, телекомпании.

Нет, это не сюжет книги, это реальность сегодняшнего дня!
Решение для обеспечения безопасности поссорилось с сервисами Microsoft, что привело к такому результату.

"…Корейское издание Money Today цитирует попросившего не называть его имени эксперта в сфере информационной безопасности, который назвал в качестве возможной причины сбоя проблемы с программным продуктом Falcon Platform американской компании CloudStrike.

По его мнению, в ходе обновления этой программы, использующей облачные технологии и применяющейся для блокировки кибератак, мог возникнуть конфликт с операционной системой, который и привел к сбою. И поскольку данное ПО устанавливается преимущественно крупными компаниями и организациями, то проблемы с работой информационных систем затронули именно их." - TG Канал @bbbreaking

🔜 Мы с вами наблюдаем типовую реализацию риска отложенной интеграции, увы далеко не первый и не последний раз. Вспомнить, хотя бы, катастрофу Boeing 737-MAX.

🔥 Не забывайте, что в продуктовой разработке существует как продуктовый, так и технологический риск.

Хотите научиться управлять рисками и ограничивать их стоимость?
🔜 Приходите к нам на Professional
Scrum Product Owner.

🙂 Существенно дешевле, чем потерять 15,61% стоимости акций, как Crowdstrike или 1,99%, как Microsoft.

Читать полностью…

Воркшоп по декомпозиции через неделю!

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

🗓 24 июля
➡️ Регистрация по ссылке
💙 Скидка 10% от нашего инженерного тренера по промокоду LOBIN

Читать полностью…

В чем разница между продуктом и проектом?

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

"Продукт" определяется как "нечто, произведенное в результате работы или усилий" или как "результат действия или процесса" и ведет свое происхождение от латинского глагола produce(re), "заставлять существовать".

🔜 То есть, если проект - это процесс с началом и концом, то продукт - это результат процесса.

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

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

Бесконечная игра
В книге "Бесконечная игра" есть интересная мысль:
"Если конечная игра имеет конец и явного победителя, как спорт, политика и война, то бесконечные игры, как наша жизнь, страны, карьера, - не имеют четкого и определенного конца и победителя.
В конечную игру играют ради победы, в бесконечную - ради продолжения игры.
Многие проблемы, с которыми сталкиваются организации, существуют просто потому, что их лидеры играют с конечным мышлением в игру, которая не имеет конца. Лидеры, которые принимают бесконечное мышление, напротив, строят более сильные, более инновационные, более вдохновляющие организации".
Проекты - это конечные игры, а продукты - бесконечные игры.

Это адаптированный перевод статьи Джока Торреса.

Наши тренинги по работе с продуктом:
⭐️ Professional Scrum Product Backlog Management Skills
⭐️ Professional Scrum Product Owner
⭐️ Professional Scrum Product Owner Advanced

⚡️ Даем скидку при покупке двух и более тренингов

Читать полностью…

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

Big Hairy Audacious Goal (BHAG) (произносим bee-hag) - это концепция, введенная Джимом
Коллинзом и Джерри Поррасом в книге «Построенные навечно: Успех компаний, обладающих видением»

Подобно лунной миссии, настоящая BHAG понятна и служит объединяющим фактором, создавая огромный командный дух.
У нее есть четкая финишная черта, поэтому организация знает, когда достигнет цели; ведь людям нравится стремиться к финишу.
BHAG вовлекает людей - она захватывает их до глубины души. Она осязаема, заряжает энергией, нацеливает на результат. Люди "понимают" ее сразу же; она практически не требует объяснений.
Это что-то простое. Сама цель - гора, на которую нужно подняться, - настолько проста для восприятия, настолько убедительна сама по себе, что ее можно было сказать сотней разных способов, но при этом она понятна всем.

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

Примеры BHAG
🔵Microsoft в 1980-х годах ставил цель "компьютер на каждом столе и в каждом доме".
🔵 Цель SpaceX "колонизировать Марс" до сих пор движет Маском и его командой.
🔵 У Meta несколько BHAG: «сделать мир более открытым и связанным» и «дать каждому возможность поделиться чем угодно с кем угодно»
🔵 Google по-прежнему хочет "организовать мировую информацию и сделать ее универсально доступной и полезной

Почему BHAG важны?
1️⃣ Мотивация
2️⃣ Фокус
3️⃣ Инновации

Подумайте о своей собственной организации
Если ли у вас цель, создающая импульс всей работе? Заставляет ли она людей двигаться вперед? Находят ли они ее стимулирующей, захватывающей, авантюрной? Готовы ли они вложить в нее свои творческие таланты и человеческую энергию?

⭐️Если такой "большой, волосатой, дерзкой" цели нет, то может быть самое время ее создать?

Читать полностью…

В Скраме нужно делать релиз в конце Спринта. Правда или ложь?

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

Что это означает в применении к нашему вопросу?

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

Также правила Скрама не ограничивают, сколько раз вы поставляете Инкремент вашим пользователям. Если вы технически можете делать поставку более одного раза в Спринт, то можете делать поставку так часто, насколько вам позволяет ваш уровень технического совершенства. В Netflix, например, количество релизов в день исчисляется сотнями, в Google - тысячами.

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

О том, как работать в настоящей Скрам-команде и как минимум раз в Спринт поставлять полезный Инкремент продукта, мы обучаем на тренинге APS-SD. Ближайший тренинг состоится 18-20 сентября, регистрация уже открыта.

Читать полностью…

Вы выбрасываете 50% своих денег.
А в США софтверным компаниям это обходится в 2.08 триллиона долларов в год. Это стоимость дефектов, согласно исследованию.
А еще добавьте сюда стоимость технического долга, о которой мы писали.

Согласно другому исследованию:
🟡 6.5% ошибок возникают на этапе прояснения требований,
🟡 25% - при проектировании,
🟡 а еще 15% в результате неудачных попыток починить предыдущие дефекты.
🔘 На долю кода приходится всего 25% ошибок.

В январе 2021 года на форуме Software Intelligence Forum компания Accenture признала, что, по ее данным, основанным на 1000 проектах, до 35% дефектов вызваны проблемами с прояснением требований.

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

Не хотите терять так много? 🔜 Снизьте свои ожидания от количества поставленных фич вдвое. Инвестируйте это время (и деньги) в продуктовое и техническое качество.

А еще приходите на наш воркшоп по работе с бэклогом продукта.
🔜 Научим соблюдать баланс между новой функциональностью, техническим долгом и работой над предотвращением дефектов.
💬 Если верить статистике выше, ROI воркшопа стремится к бесконечности.

Читать полностью…

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

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

Как получить ретроспективу в Miro?
🟡Просто скопируйте фреймы на свою доску
⚠️ Чтобы копировать с доски, вы должны быть залогинены в miro.
или
🟡Скачайте файлы для любого другого инструмента

Готово!

🔔 Приглашаю узнать еще больше о ретроспективах на воркшопе. Регистрация открыта, буду рада вас видеть!

#ретроспектива

Читать полностью…

Уже через неделю мы проводим онлайн тренинг Professional Scrum Product Owner Advanced

Это официальный тренинг для Владельцев Продуктов от Scrum.org второй ступени.
После тренинга будет возможность сдать экзамен и получить сертификацию от Scrum.org PSPO II

🍀 8-10 июля
📎 Успевайте занять место

Читать полностью…

«Никому не не нужен Скрам» – как вам такое?

🔜 Организациям нужны не фреймворки, а результаты, которые они могут дать, если они соотносятся со стратегией компании.
⚡️ Наш партнер Роман Дорошенко и Антон Скобин из Слёрм обсуждают эту тему и многое другое в свежем подкасте.

Выбирайте любую платформу для прослушивания https://slurm.mave.digital/ep-54

Читать полностью…

Мы РАЗЫГРЫВАЕМ БИЛЕТ на Летний Agile-ретрит

Мы придумали событие, где можно обменяться опытом и найти вдохновение, расслабиться и встретить единомышленников. Мы назвали его Аджайл-ретритом.
🌸 Вас ждут воркшопы от организаторов и Open Space, где можно заявить и обсудить любую актуальную тему.
📍 Летний Agile-ретрит пройдет 12-13 июля в Подмосковье.

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

🌞Среди самых теплых отзывов и выберем победителей 8 июля!

Читать полностью…

Самое интересное за прошедший месяц

☀️ Сколько денег вы теряете на багах?
Ужасающие данные исследования. Инвестируйте время (и деньги) в продуктовое и техническое качество.

☀️ Большая волосатая дерзкая цель, цель, которая вовлечет людей и захватит до глубины души. Есть ли такая у вас?

☀️ Пример реализации риска отложенной интеграции, который “сломал” аэропорты, авиалинии, банки, платежные системы, телекомпании. Учитесь управлять рисками.

☀️ Пользовательские истории - типичные ошибки и что с ними делать.

☀️ Почему индивидуальные OKR не работают. Опыт Spotify.

☀️ За кулисами написания Agile Манифеста или о том, как творилась история.

☀️ Скрам-мастер есть, а результата нет? О том, что влияет на работу СМ.

Спасибо, что читаете нас❤️

Читать полностью…

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

И как же приятно приводить примеры знакомых нам компаний.

У Сorporate-rebels нашла большую статью про ВкусВилл. Посмотрим, как устроено управление у них.

ВкусВилл отказались от традиционных подходов и иерархии менеджеров. Вместо этого они стали пионерами уникального подхода, получившего название "За пределами Тейлора". Несколько интересных аспектов:

1️⃣ Отсутствие руководителей среднего звена.
Власть радикально децентрализована. Команды управляют своими магазинами так, как будто это их собственные магазины. Это позволяет им нести ответственность за свой магазин. Магазины сами нанимают и увольняют своих сотрудников. Нанимая своих коллег, ВкусВилл делает так, чтобы магазины сами брали на себя ответственность. Они ищут новых людей, проводят с ними собеседование и верят, что новый сотрудник будет приносить пользу команде. Если окажется, что это не так, они могут винить только себя.

2️⃣ Принцип "дублирования".
Когда компания начала стремительно расти, они внедрили принцип "дублирования". Подобно дублированию клеток в нашем организме, ВкусВилл пытается дублировать все в компании и вокруг нее.
Например, сотрудников. Если для одного сотрудника слишком много работы, он "дублирует" себя, нанимая нового человека в помощь. В результате работу могут разделить два человека, которые остаются равными, что исключает иерархию.
По такому же принципу "дублируются" и отделы. Например, в ВкусВилл есть два юридических отдела, и у сотрудников есть выбор работать в одном из них. Таким образом, между отделами возникает здоровая конкуренция, направленная на создание как можно большей ценности.

3️⃣ Система “обещаний”.
Для того чтобы расти, не опираясь на традиционную иерархию, ВкусВилл принял систему саморегулирования, основанную на "обещаниях".
Система обещаний начинается с так называемых "основных обещаний". Это обещания, которые компания дает покупателю - предлагать свежие и здоровые продукты, доступные и удобные. Затем сотрудники магазинов обязуются выполнять ряд "вспомогательных обещаний", направленных на выполнение основных обещаний. А люди в штаб-квартире обязуются выполнять набор "периферийных обещаний", чтобы поддержать две другие категории обещаний.
В этой системе обещаний все имеют внутренних или внешних клиентов, и все несут ответственность за ценность, которую они предоставляют. Например, сотрудники магазинов должны выполнять свои обещания перед покупателями, предлагая свежие и полезные продукты, а производители должны быть уверены в своевременной доставке заказов.

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

Читать полностью…

Приходите учиться работать с Бэклогом продукта

🟡 Пройдем путь от Цели Продукта до оценок элементов
🟡 Каждый инструмент попробуем на практике
🟡 Сертифицируем от Scrum.org

⚡️ Осталось 1 место
🔜 Успевайте присоединиться!

Читать полностью…

Хотите проверить, есть ли в вашей компании Карго-культ Agile?

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

1️⃣ Скачайте чек-лист и раздайте его своим коллегам.
2️⃣ Попросите их отметить все пункты, которые относятся к вашей организации.
3️⃣ Проанализируйте их отзывы и оцените набранные баллы:
🔵 0-2: Как вам удалось это сделать? Срочно поделитесь своим опытом с другими организациями.
🔵 3-5: Молодцы! Вы на правильном пути.
🔵 6-8: Есть места для улучшений.
🔵 9-14: Если вы еще не начали свой гибкий путь, то, вероятно, пришло время изменить свой подход.
🔵 15-20: Начните сначала - точно ли вы понимаете, что такое Agile? Это не про вашу организацию.
🔵 21-25: Либо вы еще не начали переход в Agile. Либо вы ярые последователи карго-культа. ☹️

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

⚡️ Совсем скоро у нас стартует тренинг Professional Scrum Master Advanced (PSM II)
🔜 На нем мы не разбираем базовый Скрам, а фокусируемся на работе Скрам-мастера с организацией, Владельцем продукта и разработчиками.
💬 Присоединяйтесь!

Читать полностью…

Как связаны островитяне Меланезии и современные организации?

Когда шли бои между США и Японией во время второй мировой войны, военные базы США расположились на островах Меланезии. На эти базы доставляли оружие, еду, одежду и другие грузы. Часть этих вещей доставалась коренным жителям этих островов, которые никогда раньше не видели банок тушенки, складных ножей, одежды, да и остальных предметов цивилизованного мира.

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

Когда война закончилась и военные уехали, “дары небес”, доставляемые на самолетах, — внезапно исчезли без видимых причин. Местные решили, что если скопировать поведение американских военных, то боги сжалятся и снова подарят племенам те блага, которые дарили раньше.
Коренные жители стали активно копировать действия американцев. Они мастерили ружья из дерева, наносили на грудь надпись «U.S.A» и даже строили самолеты из соломы. Туземцы делали наушники из кокосов, брали самодельные указки и имитировали приземление самолета на импровизированном аэродроме.

Сargo cult (культ грузов) — это религия «поклонения грузам».

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

Думаете карго-культ свойственнен только аборигенам? Если бы…

🔜 Имитация фреймворков. Многие считают, что работают по Scrum только потому, что дали каждому по новой роли, проводят “церемонии/ритуалы” и используют Бэклог.
🔜 Копирование процессов других компаний. Все хотят быть, как Яндекс, Гугл, Убер, Спотифай… Но процесс, который годами нарабатывался и устаканивался и хорошо работает в одной компании, зачастую просто неуместен в другой.
🔜 Следование модным трендам. Применение чего-то новенького просто потому, что это на слуху, без оценки реальной необходимости и пользы для конкретной организации. У кого-то еще нет AI? 🙂

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

Читать полностью…

При чем здесь G.O.A.T. Месси?

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

📍 У вас есть идея. Вы превратили ее в осмысленную цель. Возможно, даже сформулировали ее по S.M.A.R.T. Что еще сделать, чтобы повысить шансы получить результат?

Необходимо проверить, что на достижение цели никто внешний, например, другая команда или подразделение не влияет, то есть вы самостоятельно можете ее достичь. А еще хорошо бы проверить, что ваших сформулированных целей достаточно.
⭐️И тут приходит на помощь принцип МЕСЕ:

🔠utually
🔠xclusive
🔠ollectively
🔠xhaustive
или
🔸Взаимно
🔸Исключающий
🔸Коллективно
🔸Исчерпывающий

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

Collectively Exhaustive значит, что достижения ваших целей в сумме достаточно для получения необходимого вам результата.

✏️ Как использовать принцип МЕСЕ?
✔️ Выпишите цель
✔️ Проверьте, что вы сможете достичь ее самостоятельно, что вам не нужна помощь и нет зависимостей
✔️ Проверьте, что если вы выполните цель, то получите тот самый результат, которого ждете

⭐️Больше о целеполагании на нашем тренинге Certified OKR Practitioner
14-16 августа
Регистрация по ссылке

Читать полностью…

Скрам-мастер есть, а результата нет?

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

✖️ Недооценка роли и найм неопытных специалистов.
Организации часто нанимают неопытных Скрам-мастеров из-за бюджетных ограничений и/или недостаточного понимания этой роли. Во многом работа Скрам-мастера схожа с работой СОО. Хороший СОО пойдет на зарплату в 100 000 рублей? Не думаю.

✖️ Отсутствие возможности работать на организационном уровне.
Скрам-мастера часто не имеют полномочий и поддержки для внедрения изменений на уровне всей организации. В результате они оказываются зажатыми между ожиданиями руководства и своими собственными представлениями о роли. Скрам-мастеров ограничивают ролью на уровне команды, отдавая лишь фасилитацию и администрирование Jira, а не решение реальных проблем и улучшение процессов. Будет ли Скрам-мастер мотивирован такими условиями? Не думаю.

✖️ Скрам-мастер уговаривает, а не принимает решения.
Скрам-мастера могут предлагать изменения, но не принимать окончательные решения. Это усложняет их работу, так как им приходится “продавать” свои идеи, убеждать занятых менеджеров, у которых могут быть другие приоритеты, страхи перед изменениями, другое мнение. Можно ли быстро получить результат, если полномочий нет, а у лиц, которые принимают решения, трансформация не в приоритете? Не думаю.

✖️ Влияние менеджеров.
Скрам-мастера сильно зависят от своих менеджеров, их открытости к изменениям. Хорошие менеджеры могут значительно повысить эффективность Скрам-мастера, поддерживая культуру экспериментов и делегирования. Если менеджер не готов к изменениям или боится потерять контроль, может ли Скрам-мастер эффективно работать? Не думаю.

✖️ Скрам-мастера в изоляции.
Организации часто пытаются внедрить Agile без изменения существующих иерархий и процессов, что приводит к карго-культу Скрама и работы Скрам-мастеров. Легко ли влиять на организационные изменения, если Скрам-мастера сами ограничены и не имеют поддержки на реальные изменения? Не думаю.

💬 Верьте в своих Скрам-мастеров. Дайте им полномочия. Они могут принести результат!

🔜 А если Скрам-мастеров нет или ваши не справляются, то возьмите нашего в аренду.
Мы умеем работать, как СОО 🙂

Читать полностью…

❔ Что делает скрам-команды эффективными?

Большинство книг, подкастов и блогов предлагают советы на основе личного опыта. Однако, этот опыт не всегда применим ко всем командам. Либераторы (The Liberators) провели исследование среди 2000 скрам-команд, чтобы определить, что действительно влияет на эффективность команд.
Прочитала исследование и делюсь выводами исследования.

5 факторов эффективности скрам-команды.

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

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

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

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

⚠️ Авторы исследования советуют проводить регулярную диагностику команд как минимум по пяти основным факторам: частота релизов, сотрудничество со стейкхолдерами, автономномия, непрерывное улучшение и поддержка менеджмента. Это поможет определить слабые места и сферы для улучшения. Для этого можно использовать Scrum Team Survey.

🔍 Какой фактор хотели бы добавить вы?

#успешные_команды

Читать полностью…

Какие пользовательские истории хорошие?

Билл Уэйк один из основоположников Extreme Programming придумал удобную аббревиатуру для 6 ключевых характеристик хорошей пользовательской истории:
I — Independent (Независимая)
N — Negotiable (Обсуждаемая)
V — Valuable (Ценная)
E — Estimable (Оценимая)
S — Small (Маленькая)
T — Testable (Тестируемая)

✏️ Как использовать INVEST?
🟡После создания пользовательской истории вернитесь к критериям INVEST и проверьте “Соответствует ли история всем критериям”.
🟡 Если какие-то то критерии не соблюдены, то “Что нужно сделать, чтобы исправить её?”
Возможно, потребуется дополнительный диалог с пользователем или работа над её декомпозицией.
🟡После корректировки проверьте историю на соответствие INVEST снова.

❓ Хотите научиться создавать маленькие и ценные пользовательские истории?
🔜 Присоединяйтесь к нашему воркшопу по декомпозиции 24 июля.

Читать полностью…

За кулисами написания Agile Манифеста

В феврале 2001 года группа из 17 экспертов в области программного обеспечения собралась на горнолыжном курорте Snowbird в штате Юта, США, чтобы обсудить набирающие популярность подходы к разработке программного обеспечения, которые тогда называли легкими методами...

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

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

💬 Почитайте, как творилась история.

Читать полностью…

Пользовательские истории - типичные ошибки

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

😥 Фокус на документации.
Одной из самых распространенных ошибок является превращение пользовательских историй в документацию, которая пишется и забывается. Карточка с историей — это не конечный продукт. Истории должны служить основой для обсуждения, уточнения и совместной работы участников команды и пользователей.
Что делать? ➡️Проводите совместные сессии по уточнению бэклога продукта, используйте фасилитацию (например, liberating structures, innovation games), чтобы вовлечь каждого участника процесса.

😥 Отсутствие обратной связи.
Даже если команда активно коммуницировала с пользователем, часто в процессе разработки теряется фокус на реальных потребностях пользователей.
Что делать? ➡️ Регулярно встречайтесь с конечными пользователями для получения обратной связи в ходе разработки. Это поможет уточнить их потребности и избежать ненужных изменений в дальнейшем.

😥Недостаток деталей.
Слишком общее описание может привести к различным интерпретациям и, как следствие, к некачественной реализации.
Что делать? ➡️Обсуждайте детали каждой пользовательской истории, включая возможные варианты выполнения. Разбейте крупную историю на более мелкие, чтобы улучшить понимание и реализацию. Например, можно использовать методику «трех уровней детализации», где история сначала описывается на высоком уровне, затем уточняются детали, и наконец, записываются конкретные шаги для реализации.

🌺На нашем воркшопе по декомпозиции, который состоится 24 июля, вы сможете углубить свои знания и навыки работы с пользовательскими историями и научиться избегать типичных ошибок.
➡️ Записывайтесь, пока есть свободные места!

Читать полностью…

Почему индивидуальные OKR не работают. Опыт Spotify.

В 2013 году мы решили отказаться от индивидуальных OKR для сотрудников.

Не поймите нас неправильно. Мы любим цели, приоритеты, данные и то, чтобы все двигались в одном направлении, не меньше, чем другие технологические компании.
Но было три основные причины, по которым OKR на индивидуальном уровне не приносили нам пользы:

1️⃣ Индивидуальные OKR тормозили нас.
OKR хорошо работают на корпоративном уровне, они отлично подходят для визуализации общих целей и результатов и заставляют всех двигаться в одном направлении. Но наш корпоративный уровень очень подвижен… наши цели быстро меняются, и адаптация интегрированных OKR на нескольких уровнях, вплоть до индивидуального, отнимает время и энергию, которые мы просто не можем себе позволить так часто.

2️⃣ В индивидуальных OKR речь идет о том, “как”. Мы же сосредоточились на причинах.
Наш бизнес развивается с бешеной скоростью. Мы убедились, что "почему" гораздо важнее, чем "как". И нам нужно все предельно упростить. Поэтому мы сосредоточились на определении приоритетов и на том, чтобы все понимали, куда и зачем мы движемся. Исходя из этого, наши команды и отдельные сотрудники сами решают, как это сделать. И они очень хороши в этом.

3️⃣ Shit in, shit out
С той скоростью, с которой мы работаем, фундамент, необходимый для установления хороших OKR, постоянно меняется и отстает. То, что мы формулировали в начале OKR цикла, часто уже устаревало, когда мы доходили до реализации.
Мы заметили, что тратим энергию на процесс, который не приносит никакой пользы. Поэтому мы решили отказаться от него и сосредоточиться на контексте и приоритетах. Мы убедились, что все точно знают, куда мы движемся и каковы текущие приоритеты, а затем позволили командам взять на себя ответственность за то, как этого добиться.

🔜 Индивидуальные цели ставятся таким образом, чтобы они не зависели от изменений в направлении нашего бизнеса. Таким образом, наши сотрудники могут сосредоточиться на том, чтобы бизнес работал, а не на том, чтобы работал процесс OKR.

📌 Мы говорим об OKR на нашем тренинге.
Присоединяйтесь!

Читать полностью…

Самое интересное за прошедший месяц

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

⭐️ Почему новые инициативы проваливаются
Или почему серебряных пуль не существует. Синхронное и системное изменение всех частей организации - вот ключ к успеху.

⭐️ Мне плевать на Scrum... но не на эмпиризм
О важных принципах, которые и есть самое ценное.

⭐️ Организация, основная на навыках…
в которой фокус смещен с традиционных должностных ролей на конкретные навыки и компетенции сотрудников. Набирающий обороты подход.

⭐️ Сколько стоит технический долг? Сумма, от которой следующий спринт хочется посвятить только разгребанию накопившегося.

⭐️ Как генеральный директор Google использовал OKR для создания самого популярного в мире браузера.
Или о том, как 2 года не достигать целей, но продолжать бороться.

Спасибо, что читаете нас ❤️

Читать полностью…

Расписание тренингов Scrum.ru на июль

🌺 8-10 июля Professional Scrum Product Owner Advanced
Продвинутые инструменты управления продуктом для владельцев продукта и продуктовых менеджеров.

🌸 22-23 июля Certified OKR Practitioner
Основы для всех, кто занимается целеполаганием в организации.

🌸 24 июля Воркшоп по декомпозиции
Техники разбиения больших элементов Бэклога продукта на маленькие.

🌸 26 июля Воркшоп по ретроспективам
Секреты проведения эффективных ретроспектив.

☺️ Обучение на август уже можно забронировать на нашем сайте.
Все онлайн, можно участвовать из любой точки мира!

Читать полностью…

А насколько вы уверены?

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

Забирайте прекрасный инструмент от Итамара Гилада, который поможет трезво взглянуть на имеющиеся подтверждения.

Как пользоваться:
✔️ Найдите тип данных который у вас есть на диаграмме
✔️ Посмотрите, в какую категорию он попадет
✔️ Вздохните, и подумайте над способом получения более достоверного подтверждения

🔜 Еще 25+ прикладных инструментов, которые мы отработаем на большом сквозном кейсе на нашем тренинге PSPO-A.
⭐️Возможность получить подтверждение знаний международным сертификатом, как приятный бонус.
😍 Приходите!

Читать полностью…