Знакомо?

#фасилитация #пользовательскиеИстории

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

Вот почему привычный формат презентаций не эффективен:

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

2. Аристотель утверждал, что убедительный рассказ включает три важных компонента: авторитет рассказчика, логичность и эмоциональность. Часто презентации - это скучное зачитывание текста со слайда (задачки из Jira). Исследователи мозга уверены, что эмоции - самый быстрый способ "достучаться" до мозга. Рассказ наполненный эмоциями быстрее запомнится и дольше будет оставаться в памяти.

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

Подробнее здесь

Дилемма Владельца Продукта

Должны ли члены Scrum команды знать зарплату друг друга?
anonymous poll

Нет – 125
👍👍👍👍👍👍👍 70%

Да – 54
👍👍👍 30%

👥 179 people voted so far.

#открытыеЗарплаты

Интересные получились результаты.

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

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

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

Предлагаю послушать Александра Горника (генеральный директор Mindbox) о том, как они пришли к открытым зарплатам, и как устроена вся эта система у них.

https://www.youtube.com/watch?v=a1rVPIXqaDU

Очередной кейс из Mindbox. Очень рекоммендую подписаться в FB на Александра и самостоятельно изучать их опыт.

https://www.facebook.com/alexander.gornik

#доставкаЦенности #производительность

Если вы хотите повысить производительность команды, то прежде всего стоит обратить внимание на пять основных препятствий на пути доставки ценности (автор - Márcio Sete):

1. Зависимости
2. Слишком высокий WIP
3. Низкий уровень профессионализма команды и кросс-функциональности (team liquidity)
4. Ручная и рутинная работа
5. Блокеры

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

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

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

Особенно интересно узнать факторы, которые позволили реализовать историю максимально качественно.

Обратите внимание, на историю с IP телефонией.

Команда сказала, что ее получилось качественно релизовать потому что:
1. Было интересно
2. Не было людей вокруг (был фокус)
3. Были понятны перспективы развития продукта
4. Выделиться на фоне других команд

Есть о чем подумать PO команды, SM и руководству.

#трансформация

Можно сколь угодно много говорить о диджитал трансформации, аджайле и других изменениях....

Но в один прекрасный момент в отдел закупок приходит эффективны менеджер, который вводит единый регламент на закупку вантусов и ПО.

#agile #гибкость

Очень большая проблема в области гибких подходов к разработке - неверное толкование представителями бизнеса agile манифеста.

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

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

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

Для объяснения последствий подобного паттерна я использую CLD (см. ниже).

Напомню легенду:
1. Прямая стрелка - прямая зависимость (т.е. чем выше мотивация команды, тем выше скорость команды).
2. Обратная зависимость (стрелка с кругом) означает обратную зависимость переменных, т.е. чем выше скорость команды (team velocity) тем ниже time to market (T2M) или чем выше стресс команды разработки тем ниже мотивация команды.
3. Стрелка с подписью QF - сиюминутное решение, quick fix.

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

#storypoints #оценка

Майкл Кон опубликовал отличное видео по одной из самых холиварных тем - оценка задач в story points. В нем он системно рассказывает: как их использовать, что они в себя включают, и какие преимущества дают.

В общем случае SP включает сложность, объем и риски. Другими словами, SP = f(объем, сложность, риски).

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

В следующем посте я расскажу о преимуществах оценки в SP, а также о том, как помочь команде понять и принять их.

https://youtu.be/VsSaolMtkKU

#storypoints #оценка

Продолжаем цикл постов про Story Points (SP). Сегодня разберем более подробно, что это такое SP и какие преимущества получает команда, когда их использует.

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

Story Points позволяют установить размер самой задачи (так же, как кубические метры используются для определения размера ямы). Ее размер не зависит от того, сколько человек будет работать над ней, и какой у них опыт.

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

В чем преимущества использования SP?

1. В силу абстрактности оценки появляется буфер времени внутри спринта, что позволяет команде быть более гибкой.
2. Команда избегает локальной оптимизации каждого отдельного сотрудника, что также повышает гибкость команды в целом.
3. В оценке задачу принимает участие вся команда, что позволяет выявить большее число кейсов и рисков, тем самым снижается вариативность задачи.
4. В процессе оценки задачи члены команды общаются друг с другом, что позитивно влияет на кросс-функциональность.

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

P.S. - Story Points не являются обязательным инструментом для оценки элементов бэклога продукта в Scrum. Если команде удобно оценивать в часах и это успешно работает - не стоит навязывать данный способ команде.

#оценка #storypoints

Как перейти к оценке в SP?

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

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

После небольшой теоретической вводной переходите к воркшопу:

1. Совместно с командой разберите несколько задач разного уровня сложности.
2. Выпишите задачи на стикеры.
3. Попросите команду упорядочить эти задачи таким образом, что слева располагаются простые и небольшие, а справа большие и сложные.
4. Разберите еще одну или две задачи и попросите команду поместить ее в упорядоченный список.
5. Попросите команду разметить данную шкалу и присвоить историям оценки в SP (например, используя числа Фибоначчи).
6. Сохраните данную шкалу и периодически обновляйте. Получившийся инструмент будет служить вам неким эталоном, к которому можно обращаться в процессе проработки новых задач.

Схематичный пример шкалы до разметки и после.

Обычный день из жизни Scrum команды. Мой внутренний Скрам Мастер ликует.

Владельцу Продукта на заметку.

Всем привет!

Начало года - самое время обновить список книг для чтения! Очень рекомендую добавить туда - "Командный подход. Создание высокоэффективной организации" (Катценбах, Смит).

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

Например, авторы указывают, что команды которые "застряли" в своем развитии имеют следующие признаки:
1. Потеря энтузиазма и боевого духа ("Все это пустая трата времени")
2. Ощущение беспомощности ("С этим ничего нельзя поделать")
3. Отсутствие чувства миссии и понимания цели ("Непонятно, для чего это все нужно")
4. Вялые, неконструктивные, односторонние дискуссии в отсутствие искренности
5. Собрания, где главное - повестка дня, а не результат ("Это все показуха и говорильня для босса")
6. Цинизм и недоверие ("Я всегда знал, что командная работа - это чушь")
7. Межличностные нападки за спинами людей или в общении с посторонними ("Он никогда не справлялся со своей работой и никогда не справится")
8. Перекладывание вины на высшее руководство и остальную часть организации ("Если задача так важна, почему они не выделят нам больше ресурсов?")

Однозначный мастрид.