Scrumsplaining #1: Канбан — это Скрам без спринтов

«Scrumsplaining» — это феномен, когда Скрам-практик пытается объяснить, что у вас нет никакой альтернативы Скраму, даже не пытаясь понять другие подходы, наличие другой точки зрения или парадигмы. В «scrumsplaining» всё объясняется с использованием Скрам-парадигмы.

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

Это первый из серии блогпостов о Scrumsplaining.

Если вы уже работаете по Скраму, и отмените практику спринтов, то у вас вся работа будет одним нескончаемым спринтом, а значит вы начнёте практиковать Канбан.

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

Хммм. Понимаю. Итак, вам нужны спринты, чтобы люди отдыхали?

Да!

Вы серьёзно? Почему бы вам просто не останавливаться для того чтобы отдохнуть?

Люди забывают это делать. Без спринтов темп не будет устойчивым.

Понял. А что будет, если возникнет что-то очень большое, что невозможно сделать за спринт?

Ну, мы разобьем это на несколько частей. 2 или более.

Итак, вы начинаете работать над чем-то, и прежде чем закончить вы останавливаетесь в конце спринта чтобы немного отдохнуть?

Да.

А не лучше ли будет остановиться для отдыха, когда вы сделали что-то важное, но ещё не начали другую работу?

Нет. Лучше останавливаться на регулярной основе с жёстким ритмом.

Это не выглядит разрушительно? Разве нет издержек, чтобы потом вернуться к незаконченной работе?

Ну да, но это всё равно лучше, чем не останавливаться и постоянно усиленно работать.

Хммм. Скажи мне ещё раз, почему вы просто не останавливаетесь для отдыха, когда вам это нужно?

Это плохая идея.

Разве Канбан не предлагает ограничить незавершенную работу, чтобы держать устойчивый ритм?

Но многие запросы могут быть большими, и их решение потребует много времени, это не будет устойчивым.

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

Это выглядит странно. Зачем так делать? Это не эффективно проводить ретроспективу без обзора сделанной работы или без собраний по планированию.

Канбан — это не Скрам без спринтов. Канбан появился из другой парадигмы и другой философии. Канбан использует парадигму ограничения незавершенной работы и концепцию систем, описывающих сервисы с ограниченной емкостью. Новая работа втягивается в систему, когда есть возможность. Ограничение незавершенной работы создаёт стресс, который стимулирует улучшение прохождения потока работ через систему, уменьшения время выполнения работ и увеличение предсказуемости. Ожидания Уровня Обслуживания (SLE) или Соглашения об Уровне Обслуживания (SLA) используются и сравниваются с Возможностями по Обслуживания (SLC) на регулярно планируемых ретроспективах, называемых Обзорами Сервиса.

Канбан использует сервис-ориентированный и эволюционный подход к проведению изменений. Вы начинаете с того, что делаете сейчас, и разрабатываете Канбан-систему, чтобы обернуть ею ваш рабочий процесс. Канбан адаптируется к вашему существующему контексту и помогает вам улучшаться. Канбан не является декларирующим, а является адаптивным и разработан для применения в вашем контексте. Вы ограничиваете незавершенную работы и втягиваете работу в вашу систему, когда есть свободное место, поскольку какая-то другая работа была завершена. Канбан-системы покрывают всю цепочку создания ценности, перекрывающую работу множества команд. Бывают Канбан-системы задействующие в работе до 100 человек, но более типично от 20 до 30. Прогнозирование завершения работы осуществляется с использованием вероятностного подхода и выработке Соглашений/Ожиданий об Уровне Обслуживания. Во всех отношениях это отличается от Скрам.

Скрам ожидает, что вы измените свой контекст, чтобы Скрам, как декларативный и предопределенный процесс, смог появиться и начать работать. Скрам ожидает, что вы внесете грандиозные революционные изменения в свою организацию, рабочий процесс, планирование и взаимодействие с клиентами. Скрам использует ежедневные и ежеспринтовые (обычно две недели) циклы принятия обязательств в качестве катализатора для улучшений. Скрам разбивает время на периоды, называемые Спринтами, он явно не ограничивает количество незавершенной работы и не использует вытягивание, когда есть ёмкость. Скрам использует пакетную передачу на каждом Спринте. Скрам использует детерминистическое планирование и конкретные детерминистические обязательства. Он не использует вероятностное планирование. Скрам предназначен для работы на командном уровне, где в команде по факту могут быть от 3 до 12 человек, чаще всего порядка 6 (как и пропагандируется).

Хотя механику Канбан-системы можно было бы в общих чертах описать как «Скрам без спринтов», а один из популярных трекеров задач, адаптированный для Скрам (Rally), вообще реализует Канбан-активность, как огромный непрерывный Спринт. Ошибочно описывать Канбан как «Скрам без спринтов», это мешает людям увидеть применимость, преимущества и возможности Канбана.

Когда вы смотрите на Канбан через призму Скрам-парадигмы, вы получаете «Scrumsplaining!».