Канбан vs Скрам без релігії: де яке працює і чому ми обрали один

У 2024 році ми в Easylim спробували Scrum. Чесно. По книжках, з двотижневими спринтами, плануваннями, ретро, демо. Через шість місяців ми зупинилися, порахували — і повернулися до канбану. Я не «проти Scrum». У певних умовах він кращий. Просто наша команда — це не ті умови. Розкажу як я це зрозумів і коли яке справді працює.

До цього у нас була стаття «Канбан без культу» — там я писав, як ми зробили дошку в Easylim. Цей пост — про те, як я взагалі дійшов до канбану. Через спробу Scrum і відмову від нього.

Чому ми взагалі полізли в Scrum

На початку 2024 у нас було 9 людей в команді. Дошка — канбан, але хаотичний. Завжди 15 задач in progress, оцінок немає, релізи виходять «коли готово». Я подумав: треба структура. Подивився на свого знайомого з продуктової команди — у них Scrum, спринти, передбачувані релізи. Я заздрив.

Ми взяли коуча на півдня. Завели Jira (вибачте). Виставили двотижневі спринти, ввели story points, призначили Scrum Master-а (це був я, до речі — додаткова робота). Запланували перший спринт на 60 пойнтів. Зробили 38. Все, як в підручнику.

Шість місяців: що виявилося

Я тримав цей формат шість місяців. Ось що ми побачили в цифрах:

• Велосіті стабілізувалося на 42–46 пойнтів за спринт. Звучить добре. Але виявилося, що ми просто навчилися ставити пойнти так, щоб збігатися. Це не велосіті — це самообман.
• Sprint planning з'їдав 4 години кожні два тижні. Дев'ять людей × 4 години = 36 людино-годин на одне планування. Двічі на місяць. Це майже один робочий тиждень одного інженера, який спалюється на оцінки.
• 30% задач не закривалися в спринті і переїжджали в наступний. Часто — повторно. Спринт перестав бути «двотижневою порцією» і став просто датою на календарі.
• Терміни клієнтам не стали точнішими. Я думав, що Scrum дасть передбачуваність назовні. Не дав. Бо реальність ламала спринт у середу — клієнт прислав баг, який треба було гасити сьогодні.

Через 4 місяці я почав ловити себе на думці: «зачекаю до наступного спринту». Тобто я починав мислити рамками інструменту, а не реальності. Це поганий знак.

Що в Scrum реально працювало

Чесно — не все було погано. Деякі речі мені сподобалися:

• Ретро раз на 2 тижні. Це справді корисний ритуал. Ми його залишили навіть після відмови від Scrum — просто без прив'язки до спринту.
• Демо в п'ятницю. Інженери показували іншій команді що зробили. Підвищувало гордість за роботу. Теж залишили.
• Sprint goal як орієнтир. Коли спринт мав одну головну мету (а не 15 окремих задач), команда дійсно фокусувалася. Це я переніс у канбан як «фокус тижня».

Тобто Scrum дав мені 3 корисні ритуали з 7. А коштував — десятки годин планувань і відчуття, що ми граємо в гру замість роботи.

Канбан vs Скрам: коротко по суті

Я роздратовуюсь, коли в інтернеті пишуть «Канбан — це безперервний потік, а Scrum — ітерації». Це правильно, але нічого не пояснює. Дам своє визначення з практики.

Scrum — це коли ти заздалегідь приймаєш рамку «ми робимо ось ці задачі за ось цей час». Все інше — зачекає до наступного спринту. Сила — в дисципліні. Слабкість — у негнучкості.

Канбан — це коли у тебе постійний потік задач, і ти управляєш не рамкою, а WIP-лімітами. Сила — в адаптивності. Слабкість — у дисципліні (легко перетворюється на хаос).

Коли Scrum таки виграє

Я не маю мети довести, що канбан кращий за все. Scrum реально виграє в трьох випадках:

1. Велика команда (15+ людей) з кількома підкомандами. Тоді спринт — це синхронізація між групами. Без нього всі тягнуть в різні боки.
2. Продукт, де релізи прив'язані до календарних подій. Edtech до 1 вересня. Tax-софт до квартального звіту. Тут спринти співпадають з реальними дедлайнами, і це працює.
3. Команда, яка тільки вчиться працювати разом. Scrum дає рамку. Через 6 місяців з рамки можна виходити — або у канбан, або в гібрид.

Якщо в тебе команда 5–14 людей, ти не випускаєш «релізи раз на 2 тижні», а робиш безперервний потік фіч і виправлень — канбан майже завжди кращий.

Що ми зробили після Scrum

Повернулися до канбану — але не до того хаосу, який був до Scrum. Я взяв з нього найкорисніше:

• WIP-ліміт 1 задача на людину. Те, що описано у статті «Канбан без культу». Це наш найжорсткіший ритуал.
• «Фокус тижня» замість sprint goal. Не дві тижні, а 7 днів. Не «зробити 60 пойнтів», а «закінчити цю фічу і випустити».
• Ретро раз на 2 тижні — як було в Scrum, тільки без прив'язки до спринту.
• Демо щоп'ятниці — кожен показує що зробив за тиждень. Без слайдів, без записів. Просто екран → 5 хвилин → наступний.

Все. Жодних story points, жодних velocity-чартів, жодних 4-годинних планувань. Раз на тиждень — 10 хвилин біля дошки. Раз на 2 тижні — година на ретро. Все інше — робота.

Як зрозуміти, що тобі підходить

Я придумав три питання, на які треба чесно відповісти. Якщо більшість «так» — тобі Scrum. Якщо більшість «ні» — канбан.

1. Чи маєш ти продукт із чіткими «версіями», які виходять разом великим релізом? Не «фіча додалась», а «v2.1 з 12 нових фіч і змін UI».
2. Чи можеш ти захистити команду від «зробіть це сьогодні»? Тобто реально сказати клієнту/босу «ні, це в наступний спринт». Якщо ні — Scrum зломає тебе.
3. Чи в тебе більше 12 людей у команді? Якщо так — Scrum дає синхронізацію. Якщо менше — це просто ритуал заради ритуалу.

У мене всі три були «ні». Тому канбан.

Що я навчився від цього експерименту

Перше — методологія не вирішує проблем команди. Якщо у вас хаос і несвіжість на дошці, Scrum не врятує. Він просто додасть ще одну дошку поверх цього хаосу.

Друге — story points — це гра. Я не зустрічав жодної команди, в якій estimation не перетворилося б за 3 місяці у фейкові цифри. Хороші команди роблять оцінки чесно, погані — підганяють під велосіті. Обидві в результаті марнують час.

Третє — будь-який ритуал, який не дає тобі рішень, треба викидати. Sprint planning у нас не давав рішень — він просто переносив задачі з беклогу. Ретро давав. Тому ретро залишилось, а планування — пішло.

І останнє: у продукті це теж відобразилось. У Easylim ми не додавали поле «story points» і не зробили sprint-режим. Не тому, що це погано, а тому що ми не віримо в інструмент. Хто хоче — використовує custom-поля для оцінок (це підтримується), хто хоче спринти — робить його як проект з датами. Але нативно — канбан. Це наша позиція з власного болю.

Якщо ти зараз вибираєш між Scrum і канбаном — почни з канбану. Він простіший і чесніший. Якщо через 3 місяці виявиться, що тобі бракує дисципліни — додаси спринти зверху. Зробити навпаки (з'їхати зі Scrum у канбан) — складніше психологічно, бо команда вже звикла до рамки.

А якщо в тебе вже Scrum і ти задоволений — ні разу не міняй. Я не місіонер канбану. Я просто розкажу, як було у нас.