Перехід продуктових команд зі Scrum на Kanban: реалізація, метрики, висновки

Всім привіт! Мене звати Каріна Гуліда, я project manager. Не кожному на цій посаді доводиться організовувати перехід 12 продуктових команд зі Scrum на Kanban в межах однієї компанії. Але саме такі труднощі та успіхи всього процесу випали на мою професійну долю в Uklon.

В цій статті я розкажу, як понад 100 спеціалістів відмовились від спринтів на користь підходу «витягання карток з черги». Стаття буде цікава всім, хто планує або задумувався про переведення команди зі Scrum на Kanban.

Які проблеми хотіли вирішити міграцією на Kanban

В першу чергу, ми хотіли зменшити time to market — кількість часу від початку роботи над новою ініціативою до доставки її в прод. Певну частку (інколи досить вагому) займав час на очікування через появу вузьких місць у робочих процесах. Перехід на Kanban дозволив візуалізувати ці bottlenecks і надалі сфокусуватись на їх усуненні або хоча б скороченні періоду очікування.

До переходу на Kanban ми використовували методологію Scrum. Певні артефакти і обов’язкові ритуали були для нас неефективними. Далі спробую пояснити, чому.

Для виконання поставлених бізнесом цілей використовується «продуктовий план», над яким щоквартально працюють всі продуктові команди.

➡️ З одного боку, ми маємо продуктовий roadmap, що зображує, які стратегічні задачі стоять перед кожною командою.

➡️ З іншого боку, ми повинні досить швидко реагувати на зміни ринку, укріплювати конкурентоздатність продуктів, що призводить до того, що пріоритети ініціатив/ епіків/ задач можуть не один раз змінюватись.

Ритуали формування і досягнення цілей на спринт здавались нав’язаними та надлишковими, адже сформовані цілі вже були зафіксовані в продуктовому плані. «Декомпозиція» цілей на спринти не додавала прозорості процесу, а тільки забирала цінний час команди на оцінку задач в story points, проведення регулярних мітингів, які часто були формальним слідування підходів і правил Scrum.

Етапи переходу, оптимізація процесів, переваги Kanban на власному досвіді

Важлива складова переходу на Kanban — перебудова робочого процесу. У нас з’явились активні стани роботи команди (active states) та стани черги (queue states). Впровадження станів черги в наші процеси дало змогу ефективніше керувати роботою команд і підсвітило можливості для вдосконалення, яких раніше видно не було.

Фактор, який найбільше впливає на терміни випуску нового функціоналу — час очікування. Він може швидко збільшуватися та накопичуватися. Це може бути пов’язано з внутрішніми чи зовнішніми чинниками, важливішими тасками, на які переключається команда, або дефектами, що виникають в процесі.

Візуалізувати всі ці проблеми допомогли статуси черги в робочому процесі: Ready for Development, Ready for Review, Ready for QA, і т.д. Окрім підсвічування вузьких місць, новий підхід знімав навантаження з команд. Задачі витягувались зі стовпців черги поступово, кожний учасник команди залишався зосередженим на поточній тасці.

Вимикалась багатозадачність. Помітила, що коли таски безперервно почали переходити з однієї фази процесу в іншу, це підвищило ефективність взаємодії команди. Значно зменшилась кількість питань в чатах, на зустрічах. Kanban дошка команди стала єдиним джерелом правди і актуального статусу тасків.

До плюсів Kanban також віднесу обмеження кількості задач, що знаходяться в роботі — WIP ліміт (work in progress limit). Оптимальний WIP-ліміт для команди залежить від кількох факторів. Різноманітні рекомендації зводяться до того, що потрібно встановити обмеження на рівні, коли кожний учасник команди тримає в роботі 1-2 задачі.

Розділення всього процесу розробки на активні та пасивні фази дає можливість вимірювати додаткові Kanban метрики. Адже неможливо покращити те, що неможливо виміряти.

Ефективність потоку (Flow Efficiency) — один із ключових показників, який допомагає знайти можливості скорочення часу очікування. По суті це співвідношення між активним часом роботи команди і загальним. Що вища ефективність потоку, то швидше й легше виконуються завдання.

Джерело: getnave.com

Від оцінювання задач до прогнозу термінів виконання

Ще одним ключовим показником у Kanban є Cycle time. Ця метрика показує, скільки часу задача перебувала в розробці від моменту, коли над нею почали працювати, до моменту, коли вона пройшла фазу доставки.

Враховуючи середній Cycle time, кількість задач, пропускну спроможність кожної команди, ми почали будувати більш точні прогнози, які спирались на унікальний досвід певної продуктової команди. У результаті, відмовились від оцінки задач в годинах або story points. Адже оцінки за визначенням не є точними і на них впливають численні фактори ризику. Kanban пропонує прогнози майбутнього на основі даних, заснованих на ймовірності, використовуючи лише минулий досвід.

З чим виникали складнощі

Звісно, перехід команд на нові правила не був позбавлений труднощів і факапів. Будь-який процес показує свою ефективність тільки при належному контролі слідування правилам, які цей процес передбачає.

Помилка, яку припустили на самому початку: недостатньо замотивували команди на зміни. Не було достатнього і чіткого пояснення цінності переходу на Kanban. Як наслідок, учасники команд недостатньо слідували правилам, які передбачала система. В деяких командах був відсутній контроль за метриками, тобто всі сигнали про проблеми просто не помічались і позитивних змін в робочих процесах не було помітно.

За допомогою командних ретроспектив ми почали виявляти недоліки і поступово виправляти їх. Сьогодні налагоджувати роботу в командах допомагають Engineering managers (вони як раз займаються контролем робочого процесу в командах). Це новий юніт, фактично, нова роль, поява якої в Uklon плюс-мінус збіглась в часі з переходом на Kanban.

Kanban Analytics

Існує кілька специфічних для Kanban діаграм, які допоможуть керувати процесом роботи команди. Оскільки активно ними користуюсь, коротко опишу їх користь:

1. Cumulative Flow Diagram — один з найкорисніших аналітичних інструментів для управління робочим процесом. Він забезпечує стислу візуалізацію найважливіших показників вашого робочого процесу. Головна мета діаграми — продемонструвати, наскільки стабільний потік, і показати, де зосередитися, щоб зробити процес гладкішим та ефективнішим.
2. Cycle Time Scatterplot — показує, скільки часу потрібно для виконання окремих робочих елементів на дошці Kanban. Діаграма візуалізує час виконання завершених задач, допомагає знайти вузькі місця, відстежити тенденцію, як змінюється Cycle Time команди.
3. Cycle Time Histogram — показує загальний розподіл часу виконаних завдань, тобто скільки задач з різним Cycle Time було виконано командою. Налагоджені процеси і злагоджена робота команди будуть давати в результаті більшість задач з плюс-мінус однаковим Cycle Time. Стабільний темп роботи команди допомагає будувати надійні прогнози.

Висновок

Kanban метрики, засновані на попередньому досвіді, дозволяють будувати більш точні прогнози, враховуючи як оптимістичні, так і песимістичні сценарії.

Перехід на Kanban зробив наші процеси більш гнучкими, а команди — готовими реагувати на зовнішні і внутрішні зміни. В тому числі завдяки Kanban після початку повномасштабної війни в Україні, ми змогли швидко змінити пріоритети у наших продуктових планах, викреслити не актуальні на той момент цілі, і в досить стислі терміни випустити нові проєкти «Волонтер» і «Евакуація» на базі наших продуктів.

Відмова від спринтів, перехід на Kanban і впровадження підходу «витягування карток з черги» дозволив бізнесу, насамперед Product owners, змінювати пріоритети роботи до моменту її початку. Це ефективний спосіб залишатися готовими до змін ринку, оскільки команда завжди працює саме над тим, що найважливіше та найпріоритетніше на даний момент.