agilixru | Unsorted

Telegram-канал agilixru - Scrum.ru / Agile, менеджмент, эффективность

2703

Пишем об организационной, командной и личной эффективности. Помогаем сделать организацию гибкой и внедрить в работу Agilе, Scrum и LeSS. Автор - Маша Товпинец, партнер Scrum.ru Вопросы @Mary_Tovpinets

Subscribe to a channel

Scrum.ru / Agile, менеджмент, эффективность

— Это означает, что я должен встретиться со своим прошлым. Я так долго убегал от него...
[Рафики бъет Симбу по голове]
— Ой! Что это было? За что?
— Это было твое прошлое.
— Больно ведь.
— Да, прошлое может причинять боль. Можно или убегать от него, или научиться чему-то.

Ребята, это не не просто ретроспектива, а настоящая стратегическая сессия😍. Проводила такую сессию в январе оффлайн, решила переложить ее в miro.
Если бы я использовала оценки сложности для каждого ретро, то эта бы получила 5 из 5 😈

Вас ждет:
Ecocycle Planning
What, So What, Now What
и еще один инструмент, который я наскоро описала, но обещаю сделать одельный пост 🐱

🐾Проводим ретроспективу с Симбой, Тимоном и Пумбой

Как получить ретроспективу в Miro?
🟡Просто скопируйте фреймы на свою доску

или
🟡Скачайте файлы для любого другого инструмента

Готово!

☕️ Понравилась ретроспектива? Возьмите нашего скрам-мастера в аренду и он проведет подобную сессию или сессию по вашему запросу.

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

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

Scrum.ru / Agile, менеджмент, эффективность

Как фреймворк Scrum создает условия для сплоченности команды

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

Эту идею хорошо описали Либераторы:

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

Одна из проблем, с которой сталкиваются многие Scrum-команды, заключается в том, что им не хватает одной или обеих этих характеристик.
Часто Scrum-команды создаются просто путем объединения случайной группы людей. Хотя такие группы могут стать очень сплоченными и слаженными, для этого необходимы целенаправленные усилия. В противном случае они остаются набором людей, которые работают над своими индивидуальными задачами и случайно оказались в одной комнате (или канале Slack). Но это не команда. И они никогда не станут эффективными.
🐞 Сплоченность заставляет людей хотеть быть частью команды, а согласованность позволяет им работать вместе над достижением общих целей.

Фреймворк Scrum предлагает четыре тактики для сплочения людей:

Тактика 1: Общие цели
Несмотря на то, что многие по-прежнему считают Цель спринта и Цель продукта необязательными, на самом деле они лежат в основе того, что делает команды более сплоченными, а их работу - более слаженной. Ценность коллективных целей давно признана в социальной психологии. Коллективные цели делают группы более сплоченными и даже могут уменьшить конфликт.

Тактика 2: Частые возможности для общения
Это происходит как во время событий Scrum, так и вне их. Простая реальность заключается в том, что знакомство и близость способствуют сплоченности. Если члены команды часто встречаются, вероятность того, что они сблизятся, гораздо выше, чем в противном случае. Частое взаимодействие также создает множество возможностей для поиска согласованности в работе и координации работы в команде для достижения общих целей.

Тактика 3: Небольшие команды
Концепция Scrum рекомендует сохранять небольшие команды. Небольшие группы, как правило, более сплоченные и последовательные, чем большие. Когда индивидуальный вклад каждого легко определить в работе, которую выполняет команда, люди с гораздо большей вероятностью посвятят себя совместной работе и будут чувствовать удовлетворение от своего вклада.

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

Хочется еще раз подчеркнуть: не всем нужна сплоченность и не всем нужен Скрам.
‼️ Подбирайте инструменты под свой контекст.

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

Scrum.ru / Agile, менеджмент, эффективность

Right-sizing оценка задач

Story Points и T-shirt sizing — популярные способы оценки в Аджайл-командах. Однако они часто вызывают путаницу и неверно используются.
Распространенная ошибка — сравнивать между собой команды по количеству стори поинтов или оценивать их успешность по Velocity.
➡️ Вместо относительных оценок можно использовать Right-sizing подход, который не имеет таких побочных эффектов.

Right-sizing — это подход, который фокусируется на стандартизации размера задач, используя исторические данные.


💡 Основная идея в том, чтобы все задачи были не больше определенного размера, который определяется на основе прошлых данных о времени выполнения цикла (Cycle Time).

➡️ Например, команда может установить, что задачи завершаются в течение 7 дней или меньше, основываясь на 85-м процентиле времени выполнения. Для этого понадобится диаграмма рассеяния времени цикла (Cycle Scatterplot Diagram).
🔸Команда определяет, можно ли выполнить задачу в установленный срок, и при необходимости ее декомпозирует.
🔸Затем команда ежедневно отслеживает метрику Work Item Age (WIA) и активно управляет элементами, чтобы они не простаивали.

Преимущества Right-sizing
Упрощает процесс оценки. Теперь оценка сводится к простому вопросу: "Можно ли выполнить задачу в установленные сроки?"
Улучшает предсказуемость. Благодаря использованию исторических данных и активному управлению элементами.
Повышает производительность. многие команды отмечают улучшение производительности. Например, снижение времени цикла (Cycle Time) на 58% и увеличение пропускной способности (Throughput) на 44%.
Может применяться на разных уровнях. Right-sizing может быть использован не только для отдельных элементов Бэклога Продукта, но и для более крупных элементов, таких как эпики.

📍 Детальнее про Right-sizing подход вы можете узнать на нашем сертификационном тренинге Professional Scrum With Kanban (PSK), который пройдет 19-20 сентября.
➡️ Регистрация на нашем сайте.

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

Scrum.ru / Agile, менеджмент, эффективность

Осень - лучшее время для обучения и продуктивной работы

Приходите к нам за знаниями:

📍4-6 сентября Provisional Certified LeSS Practitioner (pCLP)
Разбираемся, как организовать разработку больших продуктов, затрагиваем системное мышление, теорию очередей, раскладываем по полочкам фреймворк LeSS.

📍 11-13 сентября Professional Scrum Product Owner (PSPO)
Учимся создавать продукты и приносить самое ценное клиентам, используя фреймворк Скрам.

📍 18-20 сентября Applying Professional Scrum for Software Development (APS-SD)
Разбираемся с инженерными практиками и работаем в настоящей скрам-команде.

📍 19-20 сентября Professional Scrum with Kanban (PSK)
Усиливаем Скрам с помощью практик Канбана.

📍 25-27 сентября Professional Scrum Product Owner Advanced (PSPO-A)
Даем продвинутые инструменты управления продуктом для владельцев продукта и продуктовых менеджеров.

📍 30 сентября - 2 октября Certified OKR Practitioner (C-OKRP)
Выстраиваем целеполагание в организации с упором на фреймворк OKR.

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

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

Scrum.ru / Agile, менеджмент, эффективность

Как наш мозг реагирует на изменения

Недавно я прошла обучение по Управлению изменениями в компании Джона Коттера.
Поделюсь с вами интересной темой - как наш мозг реагирует на изменения и как можно использовать эти знания для внедрения изменений в организациях.

💡 Эволюция привела человека к формированию двух-канальной системы - "Выживание | Процветание", отвечающей за многие наши реакции в условиях неопределенности.

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

2️⃣ Напротив, канал Процветания активируется возможностями и связан с чувствами предвкушения, страсти, радости и энтузиазма. Эти триггеры активируют парасимпатическую нервную систему, позволяя нашему уму расширять перспективы и размышлять, творить и сотрудничать, придумывать новые способы работы.

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

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

⭐️ Но тем не менее, основной вывод - успокоение канала Выживания и активация канала Процветания при столкновении с новыми вызовами/изменениями является ключом к процветанию организации.

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

Scrum.ru / Agile, менеджмент, эффективность

Как “резать” задачи? Вдоль или поперёк?

Чтобы ответить на этот вопрос, давайте представим себе лавандовый чизкейк…😍
Как вы будете его есть? Отдельно корж? Или только начинку? А может, только ягоды, которыми украшен чизкейк сверху?
Каждая из этих частей, безусловно, съедобна и вкусна. Но чтобы ощутить весь спектр вкусов и понять идею блюда, нужно взять кусочек, который включает все компоненты.

📌 То же самое касается разработки продукта.
Чтобы получить качественную обратную связь по новой функциональности, готовый инкремент должен включать все компоненты системы: и фронтенд, и все необходимые сервисы на бэкенде. Это снижает риск того, что вы долго делаете ненужную функциональность – самый большой риск в продуктовой разработке, по мнению Эрика Риса, автора подхода “Lean Startup”.

Может возникнуть вопрос: как выполнить весь необходимый объем работы за 1-2 недели?
🔜 Этому мы и учимся на нашем воркшопе по Декомпозиции.
📎 Записывайтесь на ближайший тренинг в октябре.

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

Scrum.ru / Agile, менеджмент, эффективность

Полезные аббревиатуры целеполагания

💚pecific-конкретные,
💚easurable-измеримые,
💚chievable-достижимые,
💚elevant — значимые,
💚ime-bound -ограниченные во времени.

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

💚requently discussed - часто обсуждаемые,
💚mbitious - амбициозные,
💚pecific - конкретные,
💚ransparent - прозрачные.

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

💚ollaborative - совместная,
💚imited - ограниченная (каким-то параметром),
💚motional - эмоциональная,
💚ppreciable - оценимая,
💚efinable - корректируемая.

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

Используйте, в зависимости от того, каких целей вы пытаетесь достичь.

И приходите к нам учиться целеполаганию.
🔜 Тренинг Certified OKR Practitioner стартует 30 сентября.

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

Scrum.ru / Agile, менеджмент, эффективность

Что делать, если Скрам не тот, чем кажется

Такое еще называют зомби-скрамом.

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


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

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

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

Scrum.ru / Agile, менеджмент, эффективность

Про миссии компаний

В 1960 году Дэвид Паккард произнес неофициальную речь в компании, соучредителем которой он являлся:

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

— The HP Way



Лучше не скажешь. И лучшего для мотивации сотрудников не придумаешь.

❤️ В карточках привожу примеры отличных миссий известных компаний.
Читаю их и прям чувствую вдохновение.

🔜 Напишите в комментариях какая вам нравится больше всего.

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

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

Scrum.ru / Agile, менеджмент, эффективность

Professional Scrum Master Advanced (PSM II) через неделю!

Вторая ступень сертификациии от scrum.org для крепеньких Скрам-мастеров.

🔥 Осталось одно место, успевайте его отхватить.
🔜 Регистрация тут

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

Scrum.ru / Agile, менеджмент, эффективность

Технический аудит

Открыватель и автор книги про Экстремальное программирование (XP) Кент Бек предлагает таким образом осуществлять внедрение инженерных практик в организации:

Берите по одной за раз, все время находя наиболее насущную проблему. И как только она будет решена переходите к следующей проблеме.


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

⚡️ Чтобы привнести внешний, независимый взгляд на инженерку со стороны, мы сделали наш продукт - “Технический аудит”.

Зовите нашего инжеренерного коуча Сергея Лобина! Он придет и проведет подробное исследование вашего процесса разработки "до последней гайки".

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

✏️ Записаться на бесплатную консультацию можно вот тут .

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

Scrum.ru / Agile, менеджмент, эффективность

Планируете внедрить OKR в своей компании? Подумайте еще раз.

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

3 признака почему OKR вам не подойдут

✖️ Ваша компания руководствуется метриками производительности
Если для вас сам процесс важнее результата, то, скорее всего, OKR станут пустой тратой времени.
OKR должны помочь измерить влияние вашей работы, а не саму работу.
Например, если ваша цель - повысить уровень удержания клиентов, ваши ключевые результаты должны отвечать на вопросы: "Удалось ли нам повысить уровень удержания клиентов?", а не "Удалось ли нам выпустить все те блестящие функции, которые, по нашему мнению, повысят уровень удержания клиентов?".

✖️ Вы не умеете отслеживать метрики
Если в вашей компании не очень любят следить за изменением метрик, то OKR будут для вас нелегким испытанием. OKR про измерение результатов. Если вы не можете отследить свой прогресс, как вы можете узнать, достигли ли вы своих целей?
Что происходит, когда у вас нет метрик для измерения отдачи от вашей работы? Вы правильно догадались - вы начинаете измерять саму работу (вернемся к пункту 1).
🔜 Вместо того чтобы сразу переходить к OKR, используйте свободное время на то, чтобы дать командам возможность определить свои ключевые показатели и создать соответствующие механизмы для их отслеживания.

✖️ У вас слишком много слоев иерархии
Вы работаете в компании с шестью уровнями иерархии между командами и топ-менеджерами. Когда вы используете OKR, каждый менеджер в цепочке хочет отразить свои приоритеты в OKR, которые будут переданы вниз по каскаду.
К тому времени, когда эти цели и ключевые результаты доходят до команд, они смешиваются и умножаются, превращаясь в беспорядочный список запутанных (и часто противоречащих друг другу) целей.
При таком сценарии командам остается только гадать, какие OKR являются наиболее важными.
🔜 Если вы хотите внедрить OKR в подобной компании, постарайтесь сделать так, чтобы OKR не были простым отражением иерархической структуры.
Вместо того чтобы просто спускать OKR на каждый уровень, вы можете способствовать развитию культуры более совместного согласования и использовать руководство в качестве проводников, помогающих командам понять, как лучше согласовать свою работу со стратегическими целями компании.

⚡️ Вывод
Если все вышеперечисленное показалось вам слишком знакомым, возможно, вам лучше обойтись без OKR.

🙂 А может, и нет.

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

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

Scrum.ru / Agile, менеджмент, эффективность

Как Владельцу Продукта не порваться, когда у него много команд

Золотое правило Профессионального Скрама: Владелец Продукта и Бэклог Продукта остается всегда один в независимости от количества команд.
Часто возникает вопрос - как один Владелец Продукта в LeSS, Nexus или другом фреймворке на много команд, может посещать все события?
🙂 Кажется, Гермиона решала этот вопрос маховиком времени…
Если у вас его нет, давайте разбираться, как Владельцу Продукта не порваться.

🔜 Вы удивитесь, но в масштабируемом Скраме мы требуем от Владельца Продукта уделять событиям не более 6-8 часов на двухнедельный Спринт. Удивлены?
Простая математика:
🟡 Sprint Planning часть 1 - 1 час
🟡 Overall PBR - 1 час
🟡 Sprint Review - 2 часа
🟡 Overall Retrospective 1.5 часа

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

В чем подвох?

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

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

Это и есть главный механизм, с помощью которого мы разгружаем Владельца Продукта, оставляя за ним  видение,  стратегию  и упорядочивание Бэклога Продукта.
🔜 Уточнение элементов делегируется командам.

Приходите разбираться, как Scrum работает на много команд к нам на тренинг Certified LeSS Practitioner
✏️ 4-6 сентября
📌 Регистрация на нашем сайте

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

Scrum.ru / Agile, менеджмент, эффективность

Как измерить успех Скрам-мастера?

Обращаемся к первоисточнику:

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

Руководство по Scrum 2020


✔️ Первая часть про понимание теории и применение ее на практике. Кажется просто - надо всех научить. Но тут дело не только в том, чтобы убедиться, что люди "следуют правилам Scrum". Истинный смысл заключается в понимании того, что стоит за элементами Скрама и правилами, которые связывают их.

✔️ Вторая часть про эффективность работы Скрам-команды. Самое интересное.
СМ не "главный". СМ не может указывать команде, как работать (это подорвет ответственность и самоорганизацию). СМ не может контролировать других людей.
Да и вообще есть много факторов, которые “влияют” на работу СМ.

На тренинге Scrum.org Professional Scrum Master мы используем слайд. Он помогает передать всю сложность темы измерения успеха Скрам-мастера.

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

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

Ближайшие тренинги для Скрам-мастеров:
✔️ PSM I для начинающих
✔️ PSM II для крепеньких
🔜 Приходите учиться настоящему Скраму.

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

Scrum.ru / Agile, менеджмент, эффективность

Что такое сплоченная команда?

Сплоченность - или социальная сплоченность - широко изучается социальными психологами.

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


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

🔜 Очевидно, что сплоченные группы встречаются и на работе. И плюсов для бизнеса у таких групп множество: в сплоченных группах ваше мотивация. Они склонны лучше работать, лучше справляться со стрессом и давлением.
✖️ Но высокая сплоченность также сопряжена с рисками, такими как групповое мышление и соответствие групповому мнению, эффект социальной лени и т.д.

Что делает одни группы более сплоченными, чем другие?

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

⭐️ Второй фактор - это чувство принадлежности, которое люди испытывают и выражают, будучи частью этой группы. Это когда люди называют других членов группы "родными".

⭐️ Третий фактор - это степень разделения эмоций в группе. Это происходит, когда члены группы вместе празднуют успехи или когда испытывают гнев.

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

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

Scrum.ru / Agile, менеджмент, эффективность

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

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

🍀 11-13 сентября
📎 Успевайте занять место

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

Scrum.ru / Agile, менеджмент, эффективность

Сентябрь - время учиться не только для школьников!

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

Например, в каналах из подборки «Образование и Наука».

Сохраняйте папку, читайте, образовывайтесь. 🙂

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

Scrum.ru / Agile, менеджмент, эффективность

Самое интересное, чтобы ничего не пропустить

🔥 Как Владельцу Продукта не порваться, когда у него много команд?
Экономить время и не ходить на все события подряд.

🔥 Чайка-менеджер - почему это плохо и как “отбиться” от такого?

🔥 Что такое сплоченная команда?
И четыре фактора, которые делают одни группы более сплоченными, чем другие.

🔥 Обзор книги “Социальный мозг”.
Снова про создание высокоэффективных команд.

🔥 Когда есть смысл проводить рефакторинг.
Моя любимая рубрика - “инженерка для красивых”.

🔥 Зомби-скрам.
Пособие по выживанию.

🔥 Полезные аббревиатуры целеполагания.
Smart, Fast, Clear.

Спасибо, что читаете 💛
Врываемся в продуктивную осень!

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

Scrum.ru / Agile, менеджмент, эффективность

Если вам интересны темы создания гибких организаций, то обратите внимание на каналы из папки "Гибкие технологии управления".

📖 Некоторые и сами читаем.
➡️ Подписывайтесь, есть хороший контент.

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

Scrum.ru / Agile, менеджмент, эффективность

Provisional Certified LeSS Practitioner (pCLP) через неделю!

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

📌 Успевайте занять место

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

Scrum.ru / Agile, менеджмент, эффективность

Как решают конфликты самоуправляемые команды

Нашла в working handbook Corporate Rebels описание их подхода к решению конфликтов.
Читаем и перенимаем отличные практики.

Две объективные истины
Конфликты неизбежны в любом рабочем коллективе. Их просто невозможно избежать. Поэтому можем признать два факта:
1️⃣ Конфликты неизбежны.
2️⃣ Конфликты могут быть полезными.
Конфликты и разногласия могут быть мощным инструментом, потому что они часто предоставляют отличные возможности развиваться как индивидуально, так и в составе команды.

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

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

Именно поэтому у нас есть невероятно простой процесс разрешения конфликтов:

1️⃣ Прямой разговор: Любой, кто заметил проблемы с производительностью или честностью у коллеги, обязан напрямую обсудить этот вопрос с ним. Никаких сплетен. Вы должны обратиться к нему лично.
2️⃣ Медиатор со стороны: Если двое коллег не могут разрешить проблему, они могут привлечь медиатора. Медиатором может быть любой, кому доверяют обе стороны. Но есть важное условие: медиатор не будет решать проблему за вас. Он лишь предоставляет советы; решать вопрос должны вы сами.
3️⃣ Группа коллег: Если разногласие все еще не урегулировано, становится необходимым созвать группу коллег, чтобы выслушать обе стороны и продолжить обсуждение до тех пор, пока не будет найдено решение. Снова, группа дает советы, но не решает проблему за вас.
4️⃣ Назначенный арбитр: Если обсуждение заходит в тупик, в спор вмешивается назначенный арбитр, который принимает окончательное решение. В конце концов, любые споры должны когда-то завершиться. Для нас это самый справедливый способ сделать это.

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

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

Scrum.ru / Agile, менеджмент, эффективность

Менеджмент 1.0 и почему он не подходит современным организациям

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

📌Я рекомендую посмотреть его видео Reinventing the Technology of Human Accomplishment, в котором он объясняет, как родился Менеджмент 1.0 - он был разработан более века назад для максимизации стандартизации, специализации, иерархии, контроля и интересов акционеров. Хотя этот подход внёс огромный вклад в глобальное процветание, ценности, которые движут нашими наиболее влиятельными "старыми" институтами, кардинально противоречат требованиям современности — одержимость прибылью, власть, конформизм, контроль, иерархия и послушание не выдерживают конкуренции с сообществом, свободой, гибкостью, прозрачностью, меритократией и самоопределением.

📎 Поэтому традиционный менеджмент - не лучший выбор для современного мира VUCA (Volatility, Uncertainty, Complexity, and Ambiguity).

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

Да и вообще, толковый дядька, рекомендуем.

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

Scrum.ru / Agile, менеджмент, эффективность

Продуктовый менеджмент vs Линейный менеджменту Владельца продукта

Продуктовый менеджмент — зона ответственности Владельца Продукта:
🟡 видение и стратегия продукта,
🟡 дорожная карта и планирование релизов,
🟡 максимизация ROI,
🟡 работа с заинтересованными лицами,
🟡 конкурентный анализ и т.д.

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

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

Очень часто это тоже навешивают на Владельца Продукта.

Типичная проблема в масштабируемом Скраме (LeSS) — перегруженность Владельца Продукта. Как ему помочь?
🔜 Избавьте Владельца Продукта от линейного менеджмента и передайте его… менеджерам.

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

📎 Посмотрите на обязанности вашего Владельца продукта. Заберите с него задачи линейного менеджера.

Приходите разбираться, как организовать разработку на много команд на наш тренинг Certified LeSS Practitioner (pCLP)
⭐️ Ближайшая группа 4-6 сентября
⚡️ Регистрация по ссылке

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

Scrum.ru / Agile, менеджмент, эффективность

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

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

Напоминаю, что:
1️⃣ все изменения мы проводим с тестами, и они должны оставаться “зелеными”. Это помогает нам быть уверенными, что система работает, как и прежде.
2️⃣ нужно четко разделять фазы написания кода и рефакторинга, апологеты экстремального программирования (XP) говорят о двух шапках рефакторинга.

Итак, когда же нужно рефакторить?

1️⃣Перед добавлением новой функциональности. Кто-то, возможно, вы сами, уже писал этот код, но с новыми требованиями внесение изменений в него стало неудобным. Значит, сейчас самое время пересмотреть структуру кода, чтобы упростить последующие правки.

2️⃣После написания кода. Вы написали кусок кода, он делает то, что нужно, позаботьтесь о тех, кто будет с ним работать потом. Как любит повторять Кент Бэк, автор XP:

"Make it work, make it right, make it fast"

3️⃣Правило трёх. Удивительно, но разработчики тратят больше времени на чтение кода, а не на его написание. Дядя Боб Мартин, говорит про соотношение 10:1. Поэтому, если вы можете сделать код более читаемым, сделайте это, однако, правило трёх гласит, что не нужно бросаться менять неудачный код сразу же, (помните про экономику?) если наткнулись на него в первый раз, запомните, если во-второй - подготовьтесь, в третий - можно смело рефакторить.

4️⃣При разработке через тесты (TDD). Когда вы работаете по TDD, рефакторинг уже заложен в процесс:
❌ пишете “красный” тест
необходимый код для того чтобы тест “позеленить”
🔄 рефакторинг. Важно отметить, что вы можете изменять как структуру кода, так и тестов, в этом случае код вам будет помогать убеждаться что ничего не сломалось в поведении.

О том как применять рефакторинг и другие инженерные практики, используя фреймворк Скрам, мы обучаем на нашем самом инженерном тренинге по Скраму и самому скрамному тренингу для инженеров - Applying Professional Scrum for Software Development (APS-SD). Ближайший тренинг в сентябре 📆, регистрация тут.

Приходите сами и приводите с собой свою команду!

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

Scrum.ru / Agile, менеджмент, эффективность

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

Это гостевой пост от канала Фари @Xuyanet (РОСЛОВЕЦ, если быть точным)

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

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

2. Бумажки. Проблемы в пункте 1 вытекают в пункт 2. Мне кажется, что на старости лет я могу стать договорником))) я буду бабкой ,которая цепляется в бумагах ко всему и ржет от лиц всех присутствующих))))) В день с бумагами разного толка я сталкиваюсь раз 5 минимум. Кто-то это называет "операционкой". Я же называю это "ад на земле".....у меня ощущение, что меня все равно где-нибудь наебут как бы я не старалась))))

3. Кстати, никто не отменяет и того, что помимо всего прочего вам ваще-то надо ПРОДАВАТЬ! Кто сказал, что когда вы создали компанию, вы будете, как тот математик что пишет красивые формулы на прозрачном стекле? Думаете теперь будете только и делать, что думать о стратегии, росте, технологии и коде? ХАХАХАХАХАХА - вы это делать будете между делом бл...хотя это то ради чего мы собственно и собрались в этой компании. Поэтому работать мы будем в свободное от этой "ОПЕРАЦИОНКИ" время))))) я утрирую немного конечно, но из за пунктов 1 и 2 я не успеваю полноценно заниматься продуктом так как бы я этого хотела...

..Поэтому наконец-то я вспомнила уроки, которые я получила на МБА по построению системы. Но это другая история. О ней я когда нибудь напишу, когда мы получим в инженерке осязаемый результат по построению систем в бизнесе. В целом некая система у нас в Инженерке вырисовывается по одному из направлений

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

Фаря - Co-founder и CPO inzhenerka.Tech-тренажеры для инженеров. Сейчас живет во Франции и ведет канал о том, чем отличается головная боль продакта и предпринимателя, как строить и растить свой IT продукт, а также про работу айти во Франции.

Вот посты, которые мне понравились и с которых рекомендую начать знакомство с каналом:

👨‍💻Продакт vs предприниматель
👨‍💻Как мы сэкономили на разработке MVP
👨‍💻Конкурент о котором забывают
👨‍💻Как меняется мировозрение продакта, когда он становится предпринимателем

Переходите на канал @xuyanet и подписывайтесь 🤼‍♀

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

Scrum.ru / Agile, менеджмент, эффективность

20 вопросов, чтобы выявить ценность

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

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

⚡️ Скачивайте 20 вопросов, которые помогут в этом.
Нашла их тут.

⭐️ Больше о работе с продуктом на наших тренингах:
🟡PSPO
🟡PSPO Advanced

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

Scrum.ru / Agile, менеджмент, эффективность

SEAGULL или чайка-менеджер (от англ. "Senior Executive that Always Glides in, Unloads and Leaves Loudly") описывает менеджера, который внезапно появляется в последний момент, врывается на совещание, разрушает всю проделанную работу своими критическими замечаниями, а затем исчезает, оставляя проект под угрозой срыва.

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

Что делать с SEAGULL:
Подумайте, как бы вы реагировали на птиц, и адаптируйте эти практики для офиса.

🟢Признайте существование SEAGULL: осознайте и обсудите случаи, когда руководитель внезапно вмешивался в процесс работы. Проанализируйте последствия таких вмешательств для проекта и команды.
🟢Не кормите чайку: оставайтесь спокойными и не поддавайтесь на провокации.
🟢Установите четкие границы: определите, на каком этапе можно вносить комментарии и предложения. Старайтесь избегать внезапных изменений в последний момент.
🟢Установите циклы обратной связи: проводите регулярные встречи и обсуждения, чтобы чайка была в курсе прогресса и могла вносить свои предложения постепенно, а не в последний момент.
🟢Держите фокус на решении: при критике со стороны чайки сосредоточьтесь на поиске решений, а не на исправлении ошибок. Задавайте вопросы, чтобы выяснить, как можно улучшить работу, а не просто угодить чайке.
🟢Создайте атмосферу, в которой сотрудники чувствуют себя уверенно и защищено, даже при наличии критики.

🤔 Есть ли в вашем окружении менеджер с репутацией чайки?

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

Scrum.ru / Agile, менеджмент, эффективность

Все одержимы идеей создания высокоэффективных команд. И мы тоже!
Очередная книга "Социальный мозг: Психология успешных групп" посвящена этой теме.

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

Делюсь тремя выводами из книги.

📖 Вывод 1 - Размер имеет значение
Когда мы думаем о командах, мы думаем об их цели, сплоченности, развитии и т.д. А вот о их размере думаем не всегда. Может ли команда быть неправильного размера, чтобы справиться с задачей? Когда команда становится слишком большой? Токсичные культуры, которые бывают в организациях - менталитет "мы и они" - могут быть объяснены размером группы? Да!
➡️ Гипотеза заключается в том, что размер мозга вида и доступное время ограничивают размер социальных групп этого вида. Для людей максимальный естественный уровень составляет 150 человек. После этой цифры взаимодействие так себе. Это число Данбара и может быть эволюционным пределом значимых социальных отношений, которыми человек может управлять в любой момент времени.
Мы можем поддерживать связи с:
🔸 нашими близкими (1 или 2),
🔸 близкими друзьями (5),
🔸 лучшими друзьями (15),
🔸 хорошими друзьями и нашим основным кругом общения (50),
🔸 хорошими знакомыми (150),
🔸 знакомыми (550),
🔸 лицами, чьи имена мы можем вспомнить (1500),
🔸 и людьми, которых мы узнаем, но не можем вспомнить имена (5000).

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

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

📖 Вывод 3 - Роль доверия и сопереживания
Доверие и эмпатия - самое важное для успешных команд. Доверие снижает стресс и способствует чувству безопасности, а эмпатия помогает понять и удовлетворить потребности и проблемы членов команды. Лидеры должны сосредоточиться на создании доверия, будучи прозрачными, последовательными и проявляя искреннюю заботу о благополучии своей команды. Эмпатию можно развить, активно слушая и оказывая поддержку в трудные времена.

#книги

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

Scrum.ru / Agile, менеджмент, эффективность

4 совета по созданию более сплоченных команд

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

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

1️⃣ Работайте вместе, по-настоящему.
Самый работающий способ!
🟡 Создайте общую цель. Ту, на которую каждый будет влиять. Тогда и координация между людьми для достижения общей цели возникнет. Вкладывайтесь в определение целей спринта и целей продукта, если работаете по Скраму или в квартальную цель, если она есть.
🟡 Если поставить общую цель слишком сложно, работайте над какой-то задачей в совместном формате:
🔜 Сворминг
🔜 Пары
🔜 Мобинг

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

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

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

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

Scrum.ru / Agile, менеджмент, эффективность

Scrum - про продукт

В обновленном в 2020 году в Scrum Guide появилось определение продукта.

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


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

1️⃣ Ограниченное проблемное пространство - трудно начать работу, если у вас безграничные возможности. Знание границ своего продукта устанавливает для команды определенные ограждения.
2️⃣ Знание своей аудитории - в процессе создания продукта участвует множество заинтересованных сторон, пользователей и клиентов. Четкое понимание границ проблемного пространства позволяет командам найти заинтересованные стороны.

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

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

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

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

Дейв Вест, СЕО scrum.org

Читать полностью…
Subscribe to a channel