Scrum framework – легкий процесний фреймворк, який допомагає людям, командам та організаціям створювати цінність за допомогою адаптивних рішень комплексних проблем. Згідно з щорічним звітом від State of Agile™ Survey - це найпопулярніший спосіб робити Agile. Посібник зі Скраму (Scrum Guide) знаходиться у вільному доступі і його можна почитати/завантажити тут.

Kanban Method – метод еволюційних змін. Був задуманий авторами, як альтернативний шлях до гнучкості - як спосіб підвищення чуйності та адаптованості без будь-якої істотної революції чи реорганізації у вашому поточному підході до роботи чи політичної структури вашого бізнесу. Офіційний посібник з Kanban Method від Kanban University доступний тут.

Вступ

Останні 11 років я активно працюю з командами, в цілому за цей час приміряв на себе 20+ різних ролей у трьох великих компаніях. Практичний досвід вдалося отримати починаючи від класичного менеджера в організаційній культурі Контролю до все ще загадкової для багатьох в IT сфері ролі Scrum-майстра на кілька команд у культурі Співробітництва та Agile.
Зараз я працюю в ролі Scrum-майстра в компанії Creatio (Terrasoft) і паралельно вже більше року в ролі Agile Coach у компанії Scrum Ukraine – проводжу навчання та консалтинг з використання Scrum та Kanban у великих компаніях.

Scrumban для команд

Працюючи в різних контекстах з різними людьми, командами, керівниками, стейкхолдерами, я трохи розібрався з тим, що таке команди насправді. І чим успішні команди відрізняються від тих, у яких не дуже виходить працювати разом, або тих, що не є командами зовсім. Працюючи по Scrum та застосовуючи Kanban-метод, можу з упевненістю сказати, що ці підходи полегшують роботу “команд”, фокусують їх на важливому та при правильному застосуванні забезпечують високу ефективність та мотивацію учасників. Scrum та Kanban чудово можуть уживатися разом, і це не шокуюча новина. Є навіть книги (яким не один рік), що описують ці комбінації. Наприклад:
- Corey Ladas - Scrumban: Essays on Kanban Systems for Lean Software Development (2008)
- Ajay Reddy - Scrumban [R]Evolution, The: Getting the Most Out of Agile, Scrum, and Lean Kanban (Agile Software Development Series) (2015)
А організація Scrum.org нещодавно випустила Канбан-гайд для скрам команд (Kanban Guide for Scrum Teams). Його можна завантажити тут.

Моя історія про Scrum+Kanban

Я не маю на меті переказувати наведені вище джерела, я поділюся деякими своїми кейсами та прикладами використання різних підходів. Цікавий випадок у моїй практиці був, коли ще у 2015-2016 роках протягом десятків ретроспектив великою Agile-командою розробки (15-17 осіб) ми формалізували окремі елементи Scrum під себе. Паралельно з кожним спринтом я збирав десятки різних метрик, що описують те, що відбувається в команді, з позиції цифр. Було практично і різноманітно.

Як виявилося пізніше, через 2-3 роки на сертифікації з Kanban (KSD+KMP), всі ці ініціативи та способи, до яких ми дійшли, експериментуючи, системно описує Kanban-метод. Іншими словами, те, що ми роками називали в команді Scrum'ом, виявилося однією з інтерпретацій Kanban'а. У мене був приємний шок, мені здається, що на той момент я дещо зрозумів про суть Канбан-методу. Особливо круто було перевірити на своїх цифрах підхід #NoEstimates, суть якого у відмові від оцінок зовсім, як зайвої втрати часу та зусиль оцінювачів. Концептуально про те, за рахунок чого можна відмовитись від оцінок завдань, я розказав у своїй минулорічній статті.

Усвідомлений і зрілий Scrum я побачив нещодавно, у 2017 році. Тоді, все зійшлося, я пройшов дві сертифікації (CSPO+CSM) і одразу після цього почав працювати у великій продуктовій компанії Creatio (Terrasoft) full-time Scrum-майстром одразу у трьох командах. До цього етапу мені зустрічалися лише окремі елементи, івенти, експерименти, підходи у дусі Scrum та Agile оточенні. Саме тут я побачив масштабний Scrum, багато команд одночасно синхронно та асинхронно працюючих над одним продуктом, як годинник. У мене з'явилася можливість бути частиною цього руху.

Останні 3.5 роки я активно експериментував, працюючи в Scrum, у тому числі використовуючи Kanban. Коли в тебе три команди, і кожні два тижні відбувається три спринти – є де розгулятися з цієї точки зору. Без моїх чарівних Scrum-команд, самотужки я б звичайно не впорався. Дякую їм за терпіння та підтримку, а моєму керівнику та стейкхолдерам – за створення можливості цим ініціативам відбутися :)
Ми перепробували справді багато чого: сотні форматів ретро, ​​передизайн внутрішніх процесів, спрощення та виключення втрат на різних етапах, точкові експрес-навчання та комплексні тренінги/воркшопи з різних тем, спроби навчитися дивитися на систему в цілому (System Thinking), щорічні Futurespective, сесії відкритих фідбеків всередині команди, пост-оцінювання завдань, всілякі варіації візуалізацій, фізичні та віртуальні дошки, визначення критеріїв Advanced Agile команди тощо.

Коли я прийшов працювати в Terrasoft (Creatio) у 2017 році, Agile-трансформація вже три роки, як відбулася, Scrum-революція сталася. Більшість вже знала, що і як робити, навіщо потрібен той чи інший артефакт, як проводити івенти, вести роадмап чи беклог, запускати спринти. Це сталося насамперед через підтримку, залученість та усвідомленість в Agile/Scrum керівництва на мега-високому рівні. Пам'ятаю, хтось з колег тоді сказав мені: “Ми не граємось зі Scrum'ом - ми так працюємо. Це наші правила взаємодії всередині та між командами.”
Виклик для мене був не в революції, а у вибудовуванні самоорганізованих і зрілих кросфункціональних фіче-команд для довготривалої роботи: ми були і є у фазі Continuous Improvement (Безперервне вдосконалення). Нам потрібно було шукати способи та підходи для еволюційних змін. Я почав вивчати різні варіанти, серед яких були XP, Teal, Kaizen, Kanban, зрештою зупинився на останньому, як найкращому в моєму випадку.

Чому Kanban?

Kanban-метод - для мене відкрився насамперед, як набір із десятків різноманітних ідей, принципів, інструментів, потокоорієнтованості, WiP-лімітів, метрик, графіків, класифікацій, які допомагають не зупинятися у розвитку процесів та організації загалом. Канбан не вимагає революцій – користь можна отримувати відразу, шляхом маленьких, але регулярних покращень. Канбан поділяє сервісну парадигму - а це означає, що будь-яку Scrum-команду або групу команд, які роблять спільний продукт, можна розглядати як певний сервіс, який має межі, у якого є замовники і є одержувачі цінності, яку цей сервіс виробляє. Такий сервіс має точку прийняття зобов'язань і точку поставки, а Канбан-метод своєю чергою застосовується як спосіб поліпшення якості обслуговування цього сервісу. Це головна ідея, все інше – маневри.

По суті Kanban не впроваджують, а застосовують до процесу, який вже є. Існує навіть правило у спільноті Канбан-практиків, суть якого звучить приблизно так: "Перше правило справжнього Канбаніста не вимовляти слово Канбан". Чому це правило може стати в нагоді? Річ у тім, що у людей з якими ви працюєте, може відрізнятися сприйняття терміна "канбан" і ви зможете зіткнутися з опором або власними інтерпретаціями ще до початку будь-яких дій. Можна використовувати окремі техніки та метрики, і вони будуть приносити користь команді.

Підсумки

Працюючи з будь-яким вже існуючим процесом, ви можете застосовувати Канбан-метод, навіть якщо цей процес організований за Scrum. У самому Scrum фреймворку вже закладено ідеї з Kanban-методу, і навпаки. Просто ці ідеї описані або існують не так очевидно для всіх. Наведу приклади: один продукт для однієї команди - чим не WiP limit = 1 для кількості продуктів, над якими працює команда в певний відрізок часу? Або як формується Sprint Backlog із Product Backlog – чим не витягуючий принцип Kanban, який використовують у Scrum? Definition of Done - чим не формалізація для однозначного розуміння перетину точки поставки? Безперервний процес Product Backlog Refinement (PBR) – мікс UpStream та DownStream, тільки він відкрито не прописаний у Scrum Guide? Є й інші приклади.

Про практики та приклади такого усвідомленого застосування Kanban-методу в рамках Scrum'у я розповідав на нашому вебінарі.

Відеозапис цього вебінару:

Посилання на Miro-доску з вебінару