Базовый Agile: Основы Scrum, Kanban и командной работы

С 26 по 28 июля участвовал в тренинге "Базовый Agile: основы Scrum, Kanban и командной работы". Тренинг дает хорошее общее представление о том, что есть Agile, где место и время для Scrum и Kanban. Из всего прослушанного я понял, что Agile — это философия гибкости (проворности), Scrum — это методология на этапах роста, Kanban — это методология сбоку/сверху для управления процессами и предприятием в целом.

День 1

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

Scrum — это простой фреймворк, описанный на 17 страницах официальной документации. Бери и делай так как написано. Если не знаешь — спроси/найми скрам-мастера. Можно использовать Scrum на разных системных уровнях. Но для верхнеуровневого управления предприятием лучше использовать Kanban (а еще лучше другие практики которые описаны ниже), внутри которого, в некоторых местах/работах/картах — может использовать Scrum для реализации проектов.

Немного пройдусь по заметкам сделанным во время тренинга.

Понравилось использование Миро для презентации/слайдов. Это выглядит круто, живо, вовлекающее. Не простое перелистывание слайдов, а перемещение доски на расшаренном экране спикера + открытая во вкладке браузера та же самая доска — дают эффект "живой" презентации. Беру на заметку, и попробую использовать в своих презентациях такой способ.
Почему умер проект Google Glass? Технология была отличной. Идея — супер. Реализация — огонь. Очки записывали других людей без их на то разрешения, людей в гугл-очках начали выгонять (порой с кулаками) из баров. Окружение пользователей очков оказалось не готово к такому нарушению приватности (права на видеозапись).
Существует модель Стейси — которая показывает стадии развития предприятия и рекомендуемые практики управления на этих стадиях. Аналог — модель Кеневин. И та и другая об одном и тоже — понять на какой стадии находится предприятие, и определить оптимальные для стадии практики. Scrum — практика стадии роста.
Немного затронули тему MVP, рассказали показательную историю с MVP Dropbox (первый рабочий продукт — это ролик). Чтобы протестировать идею необязательно создавать замысленный продукт. Можно показать/рассказать как он будет выглядеть широкой аудитории и по обратной связи (количество заявок/предзаказов) понять его ценность. А потом уже брать Скрам и итерационно реализовывать/воплощать рабочий продукт. На этапе роста предприятия главный фокус внимания должен быть на исследованиях и проверке фантазий/гипотез.
Если рост подтверждается (фантазии/гипотезы оправдываются) — нужно сосредоточиться на захвате рынка (расширить круг ЦА, давать рекламу, проводить агрессивный маркетинг, проверить возможность использования новых платформ для продукта) и быстро развивать продукт. Всё это созвучно с тем, что я читал в книге Lean Startup.
На стадии роста кипит работа, на стадии зрелости — нужна бюрократия и управление работами. Практики стадии зрелости — это ITIL, PMBok.
Практики масштабирования — LeSS, SAFe, Nexus, Spotify.
Канбан — практика сопровождения предприятия. Может быть на любых этапах.
После роста, зрелости, масштабирования наступает спад (или вираж в новый продукт и всё сначала) — на этой стадии целью предприятия является минимизации затрат, используются практики Lean (бережливого производства).
Применительно к моей работе в целом — не похоже, что нам нужны практики роста. Больше откликаются практики зрелости, когда нужно всю деятельность регламентировать, следить за процессом (слышу "процесс" — вспоминаю Канбан). Возможно, внутри каких-то отдельных проектов можно применять Скрам. Но сначала нужно взять Канбан и визуализировать все работы. Для Канбана этого тренинга очень мало, ему буквально было уделено 1.5 часа. Но спасибо за игру http://www.kanbanboardgame.com/, играю теперь вечерами.

Для Канбана есть много интересных инструментов/технологий и симуляторов/игр. Например, https://mgajdzik.com/kanban-flow-simulator/

Вернемся к Agile. Философия выражены в 4 принципах:

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

И 12 под-принципов, раскрывающие основные 4:

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

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

Погуглив после тренинга нашел практику STATIK — это Systems Thinking Approach to Introducing Kanban — Системный подход для освоение Канбана. То, что мне очень откликнулось и легко на продолжающее обучение системного мышлению.

Самое важное, что я выделяю в Agile — это общение. Общение внутри команды, команды с пользователя, команды с инвесторами.
Аджайл — это всего лишь принципы, вокруг которых созданы разные методологии. Среди которых в живых остался только Скрам.
Канбан — это не Аджайл. В Канбане люди организуются вокруг процесса. Это может быть процесс поставки ценностей. Внутри которого будет применяться Скрам.
Периодически нужно открывать руководство по Скраму и делать сверку внедренного скрама. Очень часто Скрам в организациях может быть Карго-культом, когда все ритуалы есть и выглядят похоже, но руководство идеологию не поддерживает/философию не разделяет и эффективность такого Скрама не раскрывается.

День 2

Второй день начался с объяснения цикла Деминга-Шухарта — PDCA — Plan, Do, Check, Act. Основное, что тут стоит запомнить — это то, чем быстрее этот цикл у нас прокручивается, тем лучше для нас.
Скрам — это итеративно-инкрементальный подход. Итеративный — значит, что он повторяется с течением времени. Инкрементальный — каждая итерация создает новый инкремент, конечный рабочий продукт, которым можно пользоваться.
Хорошее объяснение на картинке с Моно Лизой.

Задачи в Скраме могут иметь приоритеты. Приоритет для задачи — значит ценность для бизнеса. То есть чем больше денег/ценности принесет задача (или убережет), тем выше приоритет этой задачи на доске.

Для стадии роста и гибких процессов хорошо подходит модель описания продукта Lean Canvas. Ее можно использовать для постановки задачи Скрам-команде. Это практика для роли Владельца Продукта.
Владелец Продукта — это мини-СЕО, визионер.

Выводы дня: для моей работы больше подходит Канбан. Необходимости собрать на одну доску все работы отдела, и далее распределять ее по правилам Канбана и Скрама (используется внутри проектов).

День 3

В Скрам-командах важно доверие между участниками и психологическая безопасность. Особенно важно это на ретроспективе. Одна из практик измерения уровня доверия: создаем анонимное голосование перед ретро в Миро (или на физической доске), делаем таблицу до 1 до 5 и команда анонимно вешает стикеры оценивая уровень доверия/безопасности. Если уровень низкий — ретро не выйдет, нужно отменить, анализировать (например, выгнать начальство с ретро).

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

Продуктовый Бэклог:

каждый элемент должен нести ценность, то есть являться законченным продуктом готовым к выпуску. Это может быть глава книги, функция приложения, раздел гида.
приоритеты. Здесь то же самое, что и по приоритеты в скрам доске, только еще важнее. Продуктовый бэклог должен быть приоритизирован в первую очередь по ценности/прибыльности. Чем больше ценность и ниже трудоемкость задачи — тем выше приоритет. Все мы хотим меньше работать и больше за это получать. Приоритеты также выставляются по зависимостям задач друг от друга. Если одна важная/ценная задача не может быть выполнена без другой, но приоритет другой задачи должен быть поднят.
Живой. Бэклог должен быть живым, там не должно быть протухших задач. Добавление, удаление, переписывание задач в бэклоге приветствуется.
«Айсберг Бэклога» — детальность проработки бэклога должна быть по принципу айсберга — обозримое будущее (3-4 спринта) мы прорабатываем детально, остальное — набросками, эскизами, общими чертами.
Технический долг — тоже может являться частью продуктового бэклога, если задача имеет ценность/приоритет для всего продукта. Практики для составления продуктового бэклога: User Story Mapping, Impact Mapping, CustDev, UVP Canvas.

Далее перешли к Канбану.

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

Черный Ящик Работы

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

стикеры и доски — инструмент сбора данных

положение стикера по горизонтали означает законченность задачи
по вертикали - приоритеты
цвет - тип
размер - важность и т.д.

Первый шаг — визуализировать весь объем работ
Второй шаг: цикличность, сезонность, маркеры событий, взаимосвязи событий
На любой доске есть две важные точки: ХОТИМ сделать, и ВСЕ, СДЕЛАЛИ
Можно брать данные по задачам сколько они проходили этим две точки и построить гистограмму
Блокеры — то что препятствует работу, анализируем на каденциях
Каденция — тип митингов в канбане для анализа/ретроспективы текущей ситуации.
Уровень WIP — Work in Progress — позволяет оценить сколько работ/задач брать в работу чтобы была лучшая пропускная способность.
принципы управления изменениями:

начать с того что есть, визуализировать, собирать статистику
потом показать эту статистику ЛПР и сотрудникам, и спросить что делать? В Канбане все должны быть вовлечены в процесс.
Важно получить согласие на улучшение путем эволюционных изменений от команды.
Поощрять проявление лидерства на всех уровнях. Лидер — это роль. Каждый участник команды может быть лидером по отношению к другому.
* прекратите начинать новые задачи пока не завершены старые!

нет приоритетов, а есть стоимость задержки
https://kanbanguide.ru/
Почитать Дэвид Андресон «Альтернативный путь в эджайл»
Пройти курс: https://scrumtrek.ru/product/34/kanban-system-design-kmp-i/
Начать стоит с канбан, а потом, если захочется, то в скрам.
Инструменты канбана можно применять в скраме.
скрам когда есть гипотезы и нужно проверять
канбан когда нужно улучшить рабочий процесс.

В на этом всё. Тренинг сформировал в голове Осознанную Некомпетентность по Канбану. Зачатки Осознанной Компетентности по Скраму.

В основном, за счет того, что Скрам это простая методология для простых и маленьких задач описанная в кратком гайде. А Канбан более объемная вещь и тут я ставлю себе цель углубиться в изучение и применить в своей работе. Начать с визуализации процесса и работ вокруг этого процесса.