Як поєднувати Scrum та Kanban на практиці? | Scrum Україна - тренінги, навчання та сертифікації Agile, Scrum, Large-Scale Scrum
 
Стаття відображається оригінальною мовою.

Як поєднувати Scrum та Kanban на практиці?

Коротка стаття до вебінару, яка описує вектор дискусії.

22 лип. 2022

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-доску з вебінару

Рекомендовані заходи

тренінг
DMYTRO NEZABYTOVSKYI  

Kanban for Agile Teams - це авторський клас для охочих детально розібратися в практичній сутності Kanban-методу та навчитися застосовувати його у своїх аджайл командах.

тренінг
Олексій Кривицький  

Це офіційний інтенсивний сертифікаційний клас Scrum Alliance. Курс читає Олексій Кривицький – Certified Scrum Trainer, розробник, скрам-майстер та практикуючий agile-коуч з 2008 року.

тренінг
DMYTRO NEZABYTOVSKYI, Олександр Червінський  

Decomposition for Agile Teams – це двомодульний, 10-годинний тренінг-інтенсив для охочих докладно розібратися в інструментах декомпозиції, оцінки та пріоритезування елементів для використання у своїх Agile командах. Після закінчення навчання ви отримаєте іменний сертифікат з унікальним номером, англійською мовою – "Decomposition for Agile T...

Рекомендовані статті

Зачем изучать Kanban System Design?

В марте Scrum Ukraine проводит тренинг Kanban Management Professional I. Мы узнали у тренера Paul Klipp, зачем нужен этот курс и что он даст.

Прекращайте начинать - начинайте заканчивать: как прошел первый тренинг Kanban Basics

23 февраля Scrum Ukraine провели первый тренинг Kanban Basics. Он прошел в приятной дружеской атмосфере и, по отзывам участников, был интересным и продуктивным. Провели тренинг наши коучи, Миша Глущенко и Павел Камышов.

Ми активні в соціальних мережах і хочемо спілкуватися. Додавайтеся на нашу сторінку в facebook та приєднуйтесь до наших спільнот.

Із питань корпоративних програм:

+380 93 4974661
hello@scrum.ua

З приводу тренінгів, реєстрацій, рахунків:

+380 95 7402380
hello@scrum.ua

За всіма номерами телефонів - голос і telegram.

©2017 - 2022 Scrum Ukraine. Всі права захищені.

Політика конфіденційності