Lean vs Agile: що обрати для своєї компанії

Чи справді Lean — це лише про скорочення витрат, а Agile працює тільки в IT? Чи можна поєднувати Agile та Lean в одній компанії? Чому впровадження Lean або Agile не завжди призводить до очікуваних змін у компаніях?

Сергій Комберянов, президент Lean Institute Ukraine, експерт із Lean-трансформації, операційної ефективності та управління змінами, та Артем Биковець, засновник Simple Sense й Agile-коуч, у подкасті Radio kmbs розібрали деякі міфи про обидва підходи, пояснили, чим відрізняються їхні цілі та чому на практиці вони доповнюють одне одного. Говорять про Toyota, LEGO, Starbucks і банки, про те, як перетворити ретроспективу на стандарт і чому шаблонне копіювання рішень не працює.

Ключові тези:

• Lean — це філософія постійного вдосконалення: давати клієнту максимум цінності, використовуючи мінімум ресурсів. Скорочення витрат — лише можливий наслідок, а не мета. Зростає продуктивність на одну людину, тобто ви заробляєте більше, використовуючи ті самі ресурси.
• Agile — це передусім адаптивність. Її вимірюють двома показниками: time to change (скільки часу потрібно, щоб змінити курс) і cost to change (скільки це коштує).
• Agile виріс із Lean. Піонери 1990-х надихалися лін-виробництвом, а потім цей рух розвинувся, відгалузився й почав існувати самостійно. Kanban узагалі походить від карток Toyota, а Scrum сам по собі встановлює WIP-ліміт завдяки фіксованому таймбоксу спринту.

• Agile — не тільки для IT. Він виник у контексті, де клієнт став важливішим за виробника, а процеси мали давати змогу реагувати на невизначеність. Серед клієнтів Артема були видавництва та McDonald’s Ukraine. Проте коли ви вже знаєте, що будувати, і маєте справу зі стандартною повторюваною роботою, Agile може бути зайвим.
• Agile не дорівнює хаосу. Цінність «працюючий продукт важливіший за вичерпну документацію» не означає, що документація не потрібна. Теза «люди важливіші за процеси» означає, що в разі конфлікту перевагу надають людям і взаємодії, а потім під час ретроспективи вдосконалюють процес.
• Lean — це не тимчасовий проєкт і не справа окремого відділу. Це культура, розвиток якої ніколи не завершується і яка має охоплювати всі підрозділи. Те саме стосується Agile: без союзників на рівні керівництва це лише стікери на дошці.
• Книжку про Scrum з обіцянкою «удвічі більше за половину часу» часто сприймають буквально. Це призводить до розчарувань і нереалістичних очікувань.

• Lean без зв’язку зі стратегією веде в нікуди: це лише набір локальних оптимізацій, які демотивують людей, адже вони не відчувають глобального ефекту.
• Інструменти без розуміння ідеї не працюють. Дошка Trello без WIP-лімітів — це ще не Kanban, 15-хвилинний стендап не має тривати годину, а ретроспективу не варто відкладати до кінця спринту. У Lean проблему фіксують і вирішують одразу: stop, fix, continue.
• Планувати завантаження на 100% — погана ідея. Lean радить закладати 85%, а решту часу залишати на непередбачені завдання та вдосконалення. Це дає простір для адаптації та зростання продуктивності.
• Якщо бюджети, KPI й планування в організації жорстко регламентовані, жоден Agile цього не змінить. Трансформації найкраще починати згори — на рівні ради директорів (board level).
• Не копіюйте рішення за принципом Ctrl+C / Ctrl+V. У складному середовищі немає універсальних найкращих практик — є основа для адаптації. Стандарти (SOC, постмортеми, lessons learned) мають бути інструментом поширення знань, а не догмою. Водночас стандартизація потрібна лише тоді, коли ви стикаєтеся з повторюваними проблемами.
• Прості лінійні системи можна декомпозувати й оптимізувати частинами. Складні системи, схожі на живий організм, потребують погляду на ціле: не можна лікувати хобот окремо від хвоста.

• Скрам-майстер працює в п’яти «позиціях»: викладача, коуча, спостерігача, фасилітатора й ментора. Якщо людина не може пояснити, яку цінність вона принесла команді за рік, це тривожний сигнал. В українському IT-аутсорсингу ця роль часто зводилася до координації.
• Лін-лідер має «витягувати» ініціативу, а не «штовхати» її: формувати очікування щодо змін, а не просто ставити скриньку для ідей. Мета — суб’єктність команди, а не її залежність від одного «дорослого в кімнаті».
• Сервісна модель вигідніша за продаж людино-годин: вища ставка, менше людей і швидший результат; time & material замість fixed bid; вільний час на навчання.

• Toyota понад 70 років постійно вдосконалюється та лідирує за обсягами продажів і якістю. Її відносна «консервативність» у дизайні — свідомий вибір на користь масовості та низької частоти поломок. Успіх Toyota не тотожний успіху Японії.
• Starbucks поєднує стандартизацію з адаптивністю: кожна кав’ярня може легко підлаштовуватися під потреби своїх клієнтів. Не будь-яка стандартизація є Lean: McDonald’s жорстко контролює зміни.
• LEGO — приклад поєднання підходів: Lean на виробництві й Agile там, де компанія взаємодіє зі споживачами (конструктори, ігри, кіно, колаборації). Kodak програв, бо відмахнувся від цифрової фотографії.
• Банки змушені вдосконалюватися під тиском фінтеху та в очікуванні майбутнього вступу України до ЄС. Це добра ілюстрація того, що ключовий драйвер змін — відчуття терміновості: страх втратити або шанс встигнути.

• Lean і Agile не конкурують, а доповнюють одне одного: Lean зосереджений на ефективності та культурі безперервного вдосконалення, Agile — на швидкій адаптації й перевірці гіпотез. Вам потрібні не конкретні методи, а рішення проблем клієнтів. Запитайте себе, що болить, і лише потім обирайте інструмент.