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

Если вы хотите повысить производительность команды, то прежде всего стоит обратить внимание на пять основных препятствий на пути доставки ценности (автор - 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. Перекладывание вины на высшее руководство и остальную часть организации ("Если задача так важна, почему они не выделят нам больше ресурсов?")

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

Всегда с удовольствие наблюдаю за тем, как команда напрямую работает с бизнесом: общаются, совместно креативят, разрешают противоречия. На фото процесс PI планирования (привет, SAFe).

#SAFe #трансформация
И все же нужно признать, что SAFe очень органично ложится на существующую организационную структуру: для всех есть роли, каждый сохраняет право голоса и право вето, нужные люди сохраняют полноту контроля. Нехватка компетенций у Владельца Продукта компенсируется командой product management, а недостаточный уровень инженерной культуры «закрывается» возможностью не выливать готовый инкремент каждую итерацию и квартальным планированием архитектурных изменений.

Трансформация проходит относительно безболезненно и без особой крови. Однако если Скрам-мастера, RTE и SPC не ведут систематичную работу по «пропаганде» Agile и Lean принципов, не помогают бизнесу и командам разработки начать конструктивно общаться, все превращается в имитацию и реальной трансформации корпоративной культуры не происходит.

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

Привет! Давно не делился практиками проведения ретроспектив.

Сегодня расскажу об опыте использования инструмента «TRIZ» из Liberating Structures.

Подробнее о формате можно прочитать здесь: http://www.liberatingstructures.com/6-making-space-with-triz/

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

Сценарий для ретро:
1. Объяснение идеи и формата, разбиение на малые группы (если в команде больше 8 человек)?
2. Формулировка цели: что нам нужно делать, чтобы не достичь цели спринта (не сделать вообще ничего) и не узнать ничего нового?
3. В группах формулирование действий, направленных на провал спринта.
4. Группы представляют друг другу свои действия.
5. В группах обсуждаем, что из перечисленных действий мы делаем в любой степени (пусть даже в самой незначительной). Приоритизация и выработка решений для трех наиболее существенных проблем. Презентация результатов, сбор фидбека от коллег.
6. Доработка решений в группах, презентация финального плана изменений.
7. Мини рефлексия по формату ретроспективы.

Время: 90 минут

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

С разрешения команды прилагаю фото с данного ретро 😉

#feedback #ОбратнаяСвязь

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

Ключевые идеи:
1. Обратная связь это НЕ критика, НЕ давление, НЕ оценка, НЕ приказ и НЕ манипуляция
2. Хорошая ОС - просто информация (как действия человека выглядят с вашей точки зрения, какое влияние оказывают на вас лично, на общее дело и на процесс работы.)
3. Отсутствие ОС опаснее чем неправильное предоставление ОС (возникает кризис признания).
4. Подготовьте человека к ОС (например "Я зайду через полчасика, обсудим проект")
5. Будьте конкретны (что именно человек, на ваш взгляд, человек сделал не очень хорошо (без приказов!)
6. Помогайте человеку расти (ошибка это новый опыт, "инвестиция в знание")
7. Главное - не давить, давать конкретную информацию и не лишать человека свободы выбора.

http://www.forbes.ru/karera-i-svoy-biznes/371541-naprasnye-slova-kak-davat-obratnuyu-svyaz-s-uchetom-raboty-mozga?fbclid=IwAR2sbKnqM7XoaNEQeY5DrEjOkZDTDpls_KNLpqb7gk6mkeRHZL_MzwpZMyk&from_alt_domain=1

#NoEstimates

В процессе поиска края интернета, наткнулся на очень интересный блог, который ведет Васко Дуарт (создатель и ведущий Scrum Master ToolBox Podcast).

В этом посте на разных примерах он разбирает, почему scope buffer лучше чем time buffer, почему нужно «комититься» под сроки релиза и ROI, а не под оценку объема работ и упоминает другие важные концепции из области #NoEstimates

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

http://softwaredevelopmenttoday.com/2017/10/dont-plan-to-fail-or-how-to-never-be-late-never-ever-noestimates/