Scrum Master Notes. Страница 4
2281
@scrummasters
Привет. Я скрам-мастер (PSM I, PSPO I). Здесь я делюсь собственными наблюдениями, а также материалами, касающимися Agile и Scrum.
-
Scrum Master Notes
Как работает итеративно-инкрементальный подход в Scrum.
На скриншотах ниже три важные вехи в развитии одного из компонентов портала.
Первая версия «шапки» была создана исходя из имеющихся на тот момент требований. Постепенно добавлялись новые разделы, ограничения и пожелания пользователей, появился новый фирменный стиль. В моменте команда занималась более приоритетными задачами, поэтому в компонент вносились правки по мере их поступления. Через несколько спринтов появилась возможность переосмыслить данный компонент и выработать.
Важно, что в каждый момент времени команда принимала наиболее эффективное решение исходя из текущих приоритетов, информации и навыков. -
Scrum Master Notes
Первичное построение шкалы story points в рамках первого PI планирования нового ART #SAFe 
-
Scrum Master Notes
#ретроспектива
Павел в чате @agile_ru поделился отличным алгоритмом для разрешения ситуации, когда команда утверждает, что ей больше не нужны ретроспективы, поскольку она уже достаточно зрелая и их процесс идеальный. -
Реклама
-
Scrum Master Notes
Я делал так:
1. «Ок, ретро больше не нужны, давайте сделаем последнее, на котором обсудим наши прошлые ретроспективы»
2. На ретро просите команду написать, какую пользу они получали от ретро раньше
3. После этого по каждому пункту обсудите, почему эта польза перестала появляться (и промаркируйте) или стала не нужна.
4. Как результат вы получите список проблем с ретроспективой. Предложите команде «давайте мы подумаем, как мы можем вернуть пользу, не важно, с ретро или без».
5. Как результат вы получите action plan. Скорее всего он позволит либо сохранить ретро, но в новом формате, либо сохранить «идею» ретро, просто не в виде выделенного митинга, а в виде процесса. -
Scrum Master Notes
#advancedAgileTeams #команда
Очень рекомендую посмотреть интервью Алексея Кривицкого в рамках проекта Agile Friday.
Наиболее интересные тезисы:
- Тишина - характерный звук Waterfall
- Зрелые agile команды переходят от планирования историй к планированию целей. Представители команды разработки делят с Владельцем Продукта многие его функции.
- Внутри зрелой команды происходит постоянная ситуативная коммуникация. Вещи происходят тогда, когда нужно.
- Команды делают все, что должно быть сделано для достижения поставленной цели.
- Продвинутые команды берут на себя процессы найма и увольнения сотрудников.
- Готовы к любым экспериментам. Никогда не говорят сразу "нет". Готовы пробовать и извлекать опыт.
- Не рассуждают в категориях наше/ не наше, мой репозиторий/ не мой репозиторий.
https://www.youtube.com/watch?v=9RuragYsXXs -
Scrum Master Notes
-
Scrum Master Notes
Не могу не поделиться здесь отличным постом Ильи Павличенко и статьей Кена об истинной функции PO. -
Scrum Master Notes
Владельцы Продуктов в одном из ART синхронизируют свою работу и актуализируют планы в рамках PO sync meeting [SAFe]. 
-
Scrum Master Notes
#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/ -
Scrum Master Notes
#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 -
Scrum Master Notes
#ретроспектива #liberatingStructures
Привет! Давно не делился практиками проведения ретроспектив.
Сегодня расскажу об опыте использования инструмента «TRIZ» из Liberating Structures.
Подробнее о формате можно прочитать здесь: http://www.liberatingstructures.com/6-making-space-with-triz/
Если кратко, основная цель данной активности - поиск решений путем проведения диверсионного анализа. Команда думает о том, что нужно делать/не делать, чтобы наверняка завалить спринт и ни на шаг не приблизиться к цели спринта (а также ничему не научиться и не узнать ничего нового).
Сценарий для ретро:
1. Объяснение идеи и формата, разбиение на малые группы (если в команде больше 8 человек)?
2. Формулировка цели: что нам нужно делать, чтобы не достичь цели спринта (не сделать вообще ничего) и не узнать ничего нового?
3. В группах формулирование действий, направленных на провал спринта.
4. Группы представляют друг другу свои действия.
5. В группах обсуждаем, что из перечисленных действий мы делаем в любой степени (пусть даже в самой незначительной). Приоритизация и выработка решений для трех наиболее существенных проблем. Презентация результатов, сбор фидбека от коллег.
6. Доработка решений в группах, презентация финального плана изменений.
7. Мини рефлексия по формату ретроспективы.
Время: 90 минут
Из наблюдений: очень хорошо работает история с итеративным формулированием улучшений: команды несколько раз анализируют черновики решений для выделенных проблем, дают друг другу фидбек и дорабатывают свои предложения.
С разрешения команды прилагаю фото с данного ретро 😉 -
Scrum Master Notes
#SAFe #трансформация
И все же нужно признать, что SAFe очень органично ложится на существующую организационную структуру: для всех есть роли, каждый сохраняет право голоса и право вето, нужные люди сохраняют полноту контроля. Нехватка компетенций у Владельца Продукта компенсируется командой product management, а недостаточный уровень инженерной культуры «закрывается» возможностью не выливать готовый инкремент каждую итерацию и квартальным планированием архитектурных изменений.
Трансформация проходит относительно безболезненно и без особой крови. Однако если Скрам-мастера, RTE и SPC не ведут систематичную работу по «пропаганде» Agile и Lean принципов, не помогают бизнесу и командам разработки начать конструктивно общаться, все превращается в имитацию и реальной трансформации корпоративной культуры не происходит. -
Scrum Master Notes
Всегда с удовольствие наблюдаю за тем, как команда напрямую работает с бизнесом: общаются, совместно креативят, разрешают противоречия. На фото процесс PI планирования (привет, SAFe). 
-
Scrum Master Notes
Всем привет!
Начало года - самое время обновить список книг для чтения! Очень рекомендую добавить туда - "Командный подход. Создание высокоэффективной организации" (Катценбах, Смит).
Авторы системно подошли к описанию всех важных компонентов, необходимых для создания эффективной команды: каких принципов должен придерживаться лидер команды, какие признаки свидетельствуют о том, что команда столкнулась с серьезными проблемами, что необходимо сделать, чтобы у команды развилась коллективная ответственность за результат и многое другое.
Например, авторы указывают, что команды которые "застряли" в своем развитии имеют следующие признаки:
1. Потеря энтузиазма и боевого духа ("Все это пустая трата времени")
2. Ощущение беспомощности ("С этим ничего нельзя поделать")
3. Отсутствие чувства миссии и понимания цели ("Непонятно, для чего это все нужно")
4. Вялые, неконструктивные, односторонние дискуссии в отсутствие искренности
5. Собрания, где главное - повестка дня, а не результат ("Это все показуха и говорильня для босса")
6. Цинизм и недоверие ("Я всегда знал, что командная работа - это чушь")
7. Межличностные нападки за спинами людей или в общении с посторонними ("Он никогда не справлялся со своей работой и никогда не справится")
8. Перекладывание вины на высшее руководство и остальную часть организации ("Если задача так важна, почему они не выделят нам больше ресурсов?")
Однозначный мастрид. -
Scrum Master Notes
Владельцу Продукта на заметку. 
-
Реклама
-
Scrum Master Notes
Обычный день из жизни Scrum команды. Мой внутренний Скрам Мастер ликует. 
-
Scrum Master Notes
Схематичный пример шкалы до разметки и после. 
-
Scrum Master Notes
#оценка #storypoints
Как перейти к оценке в SP?
Во-первых, продайте команде проблему и только затем предложите решение. Подход в стиле "с завтрашнего дня используем SP" с большой долей вероятности не увенчается успехом, особенно если в команде есть скептически настроенные специалисты.
Далее расскажите команде о смысле SP, приведите ряд примеров из реальной жизни.
После небольшой теоретической вводной переходите к воркшопу:
1. Совместно с командой разберите несколько задач разного уровня сложности.
2. Выпишите задачи на стикеры.
3. Попросите команду упорядочить эти задачи таким образом, что слева располагаются простые и небольшие, а справа большие и сложные.
4. Разберите еще одну или две задачи и попросите команду поместить ее в упорядоченный список.
5. Попросите команду разметить данную шкалу и присвоить историям оценки в SP (например, используя числа Фибоначчи).
6. Сохраните данную шкалу и периодически обновляйте. Получившийся инструмент будет служить вам неким эталоном, к которому можно обращаться в процессе проработки новых задач.