Всегда с удовольствие наблюдаю за тем, как команда напрямую работает с бизнесом: общаются, совместно креативят, разрешают противоречия. На фото процесс 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/

Владельцы Продуктов в одном из ART синхронизируют свою работу и актуализируют планы в рамках PO sync meeting [SAFe].

Не могу не поделиться здесь отличным постом Ильи Павличенко и статьей Кена об истинной функции PO.

#advancedAgileTeams #команда

Очень рекомендую посмотреть интервью Алексея Кривицкого в рамках проекта Agile Friday.

Наиболее интересные тезисы:
- Тишина - характерный звук Waterfall
- Зрелые agile команды переходят от планирования историй к планированию целей. Представители команды разработки делят с Владельцем Продукта многие его функции.
- Внутри зрелой команды происходит постоянная ситуативная коммуникация. Вещи происходят тогда, когда нужно.
- Команды делают все, что должно быть сделано для достижения поставленной цели.
- Продвинутые команды берут на себя процессы найма и увольнения сотрудников.
- Готовы к любым экспериментам. Никогда не говорят сразу "нет". Готовы пробовать и извлекать опыт.
- Не рассуждают в категориях наше/ не наше, мой репозиторий/ не мой репозиторий.

https://www.youtube.com/watch?v=9RuragYsXXs

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

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

Я делал так:
1. «Ок, ретро больше не нужны, давайте сделаем последнее, на котором обсудим наши прошлые ретроспективы»
2. На ретро просите команду написать, какую пользу они получали от ретро раньше
3. После этого по каждому пункту обсудите, почему эта польза перестала появляться (и промаркируйте) или стала не нужна.
4. Как результат вы получите список проблем с ретроспективой. Предложите команде «давайте мы подумаем, как мы можем вернуть пользу, не важно, с ретро или без».
5. Как результат вы получите action plan. Скорее всего он позволит либо сохранить ретро, но в новом формате, либо сохранить «идею» ретро, просто не в виде выделенного митинга, а в виде процесса.

Первичное построение шкалы story points в рамках первого PI планирования нового ART #SAFe

Как работает итеративно-инкрементальный подход в Scrum.

На скриншотах ниже три важные вехи в развитии одного из компонентов портала.

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

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

Scream Guide - отличный сборник различных антипаттернов при использовании Scrum.

Если в этих ироничных фразах узнаете свою команду/организацию - повод задуматься и пересмотреть подход к использованию Scrum.

https://medium.com/@vladimirmerkushev/scream-guide-%D0%BA%D0%B0%D0%BA-%D0%B1%D1%8B%D1%82%D1%8C-agile-%D0%B8-%D0%BD%D0%B5-%D0%BC%D0%B5%D0%BD%D1%8F%D1%82%D1%8C%D1%81%D1%8F-3ad19ce4ad1c

Наиболее интересные цитаты.