Як ми переходили з однокомандного Scrum на масштабований LeSS

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт! Я Ілля, Head of engineering у Poster. До 2021 року ми в компанії організовували роботу за Scrum на рівні кожної окремої команди, і ця методологія цілком усіх влаштовувала. Але під час пандемії виникла потреба швидко змінити пріоритети у розробці — а зі звичайним Scrum було складно таке зробити. Це змусило нас подивитися в бік LeSS (Large-Scale Scrum). Спойлер: час показав, що це було правильне рішення.

Чому ми наважилися на зміни, як покроково впроваджували LeSS, з якими складнощами стикалися та як їх вирішували — розповім у статті.

Яку проблему відчули та чому вирішили запровадити LeSS

Щоб зрозуміти, як ми перейшли до Less та чи варто переймати наш приклад, додам трохи контексту про те, чим займається Poster. Ця українська продуктова компанія розробляє систему обліку та автоматизації процесів для HoReCa (Hotels, Restaurants, Cafe, усього 13 000 клієнтів). Сам продукт дозволяє контролювати продажі, прибуток, склад, виробництво тощо, а ще є екосистема, яку ми побудували навколо ключового продукту, як-от мобільний додаток зі статистикою та інше.

У dev-відділі Poster 44 спеціалісти: це продуктова та інженерна команди. Є два офіси: в Дніпрі та Мехіко (Мексика), але більшість людей зараз все одно працюють віддалено.

Коли почалася пандемія, більшість ресторанів закрилися для відвідувачів та перемкнулися на доставку. Тож і потребували нових додаткових функцій: наприклад, можливість запустити власну доставку, керувати кур’єрами. Ми спробували підлаштуватися під виклик. Витягли по одній людині з кожної з 12 команд — у такий спосіб зібрали «загін спецназу», який займався новими задачами.

Утім, цього виявилося недостатньо: ми не справлялися. А змінити напрямок одночасно всієї компанії для роботи над новими функціями — не змогли. Це змусило нас серйозно замислитися над тим, чи правильно ми все робимо.

Ми чітко слідували Scrum: у нас були команди до 10 спеціалістів. Кожна мала певний вузький фокус на конкретному компоненті системи. Наприклад, одні працювали з хмарною платформою, інші — з hardware-пристроями тощо.

Але проблема виявилася в тому, що кожна з команд вела власний беклог за своїм компонентом. Розробники брали з нього задачі, навіть якщо у конкретний момент часу ці тікети не були найважливішими та найпріоритетнішими для компанії та продукту загалом.

На відміну від звичайного однокомандного Scrum, методологія LeSS (Large-Scale Scrum, «Scrum на великих масштабах») надає можливість фокусуватися на чомусь одному на рівні всієї компанії.

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

Які страхи долали з переходом на LeSS

Я пройшов базовий курс з LeSS і побачив, що ця методологія може розв’язати наші проблеми. Але на початку ми не були впевнені у рішенні та мали певні сумніви.

• Страх #1: у компанії буде один беклог, а отже потрібен лише один Product Owner. Всіх інших доведеться звільнити або перевчити.

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

Ми пояснили всім PO, що кожний з них вміє організувати швидку роботу зі своїм компонентом, але не завжди конкретний елемент беклога є пріоритетним у масштабах всього продукту. Це не те, що допоможе досягти успіху.

Працівники почули цей аргумент та налаштувалися на зміни. Для PO це немов глибинна робота зі своїм его — віддати своїх розробників в загальний пул на благо компанії і самому залишитися без команди.

Отже, у компанії залишилася одна роль PO, і її забрав СЕО компанії, але в майбутньому він планує передати її Head of Product. А всі попередні Product Owners стали Product Managers і створили продуктову команду, яка допомагає PO в роботі над беклогом. Зрештою ніхто не звільнився — всі знайшли місце у новій системі.

• Страх #2: кожна команда займається складним компонентом. Тож не можна просто так віддати свій код іншим людям — вони не справляться.

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

Наприклад, одна команда раніше працювала над технічною частиною продукту, а після переходу на LeSS переорієнтувалася на домен, пов’язаний з українським законодавством. Спочатку всім було складно — але зрештою розробники впоралися. Для цього вони зверталися за консультаціями до інших команд, опанували нові інструменти взаємодії, проводили крос-командні код рев’ю.

Те саме стосується і QA: тестувальники із занепокоєнням «пірнули» у нові для себе домени. Інколи навіть доводилося відкладати фічі до того, як тестувальник з цієї команди повернеться з відпустки чи з лікарняного. Але зрештою всі адаптувалися.

Чому обрали LeSS замість LeSS Huge

LeSS Huge — це фреймворк, який підходить для адаптації LeSS у продуктах з 8 та більше команд. Концептуально, це той самий LeSS, який розширюється внаслідок того, що кілька менших LeSS-фреймворків складені один на одного. Якщо спростити, то до загального беклогу додається робота з беклогами певних областей продукту.

У нас на старті було близько 50 людей у відділі розробки — це така кількість, яка теоретично вміщується в один LeSS. І ми вирішили спершу навчити всіх інженерів та стейкхолдерів LeSS, а лише після цього разом ухвалити рішення, як запускаємось та працюватимемо далі — з LeSS чи LeSS Huge.

Ми запросили Scrum/LeSS-майстра Олексія Кривицького (він є співавтором цього матеріалу) та влітку 2021 року почали навчання. Після низки навчальних воркшопів у деякий момент сформувався консенсус:

«Давайте почнемо працювати всі разом усередині одного LeSS — адже LeSS і створений для того, щоб вчитися працювати разом».

Ми визначили для себе три основних стратегічних напрями з розробки продукту. Потрібно було сформувати для них один загальний беклог і, здавалося, що через це загубимо якісь дрібні, але важливі фічі. Ми мали відчуття, що якщо зараз не закріпимо за кожним напрямком Area Product Owners, то перестанемо ним займатися.

Як розв’язати це питання в рамках LeSS? Одна з ідей була квотувати, але ми швидко відмовилися від неї ще до старту. Ми запитали себе: «Що у нас є продуктом?». Наш use case, котрий ми вирішуємо, — це облік продажів зі складу. Це основна цінність, заради якої клієнт придбає систему. При цьому ми продаємо один цілісний продукт. Це розуміння послугувало головним чинником, щоб все ж таки стартувати з одним загальним беклогом на всіх.

Що таке LeSS Flip Event

LeSS Flip — це про переворот компанії з ніг на голову, про повну реструктуризацію. На LeSS Flip Event спеціалісти формують загальний беклог, розбиваються на нові команди та планують перший спринт за новим фреймворком.

На момент переходу на LeSS ми вже понад рік працювали віддалено через пандемію, тож логічно було б і LeSS Flip Event проводити онлайн. Але, зрештою, вирішили зібрати всіх разом в офісі. Це було одне з найкращих рішень. Після двох днів очної роботи з обговореннями, суперечками, малюванням на папері хтось з працівників сказав: «Я не уявляю, як ми могли б ось це все зробити в Zoom. Ми просто здохли б!».

LeSS Flip Event

LeSS Flip Event

Спочатку ми проаналізували стратегічні цілі компанії на пів року та склали список наших викликів. Но основі цього і прописали загальний беклог.

Потім взялися до Definition of Done (DoD). Адже ще до старту LeSS у нас був десяток команд, і кожна мала своє розуміння слова «готово». Перший прототип спільних напрацювань ми назвали DoD 1.0 — всі розуміли, що він не є досконалим. Тобто це найнижчий поріг, який всіх задовольняє. Потім склали DoD 3.0 — ідеальний, але нереальний на поточному етапі розвитку компанії. Це документ «на виріст», наша мета розвитку.

Далі перейшли до DoD 2.0, який має бути посередині між 1.0 (нашим поточним станом справ) та 3.0 (недосяжним стандартом). Ця версія вже придатна для використання у перші спринти. Крім технічних визначень, там були пункти про документацію та онбординг клієнтів — те, що раніше робилося суто поза командами.

Нарешті, ми перейшли до формування нових команд. За кількістю людей розуміли, що їх має бути шість — тож розставили стільці у формі шести кіл. Люди брали аркуші А4 та виписували на них свої навички: «Я вмію кодувати такий-то бекенд», «Я вмію тестувати», «Я знаю JavaScript» тощо. Після цього менеджери вийшли з кімнати, і пішла самоорганізація.

За 20 хвилин покликали менеджерів для зворотного зв’язку. Наприклад: «У такій-то команді занадто багато такої-то компоненти, а в інших командах її бракує». Потім — ще один цикл самоорганізації без менеджерів, але з урахуванням їхнього фідбеку. Так за кілька ітерацій ми змогли створити нові повноцінні команди.

Як організували LeSS спринти

Ми організуємо роботу за допомогою Notion — цей інструмент дозволяє керувати одним загальним беклогом, а також вести Knowledge Base з усією документацією. Крім цього, коли потрібно робити разом щось візуальне, використовували Miro (примітка: на момент виходу статті відмовились від Miro через російське походження продукту).

Ось як виглядає наша спільна дошка:

Ліворуч — дошки з ретроспективою кожної з команд, праворуч — з беклогом та плануванням спринтів

Спринт-рев’ю проводимо в Zoom. До дзвінка приєднуються всі: як співробітники інженерного департаменту, так і спеціалісти техпідтримки тощо. Це відкрита зустріч на рівні компанії, де ми оцінюємо наш продукт.

Звичайно, не все проходить гладко та ідеально. Наприклад, на старті більшість розробників мали відчуття, що ми рухаємося надто повільно. У багатьох пів спринту пішло тільки на те, щоб розгорнути проєкт. Але ми нікого не квапили, не чекали продуктивності та шалених швидкостей у перші тижні.

Я пам’ятаю, що протягом одного з перших спринтів зловив себе на думці, що саме зараз вперше за історію компанії більшість співробітників разом працюють над найважливішою бізнес-ідеєю. Так, поки що ми йдемо повільно — але у правильному напрямку.

Це і є суть LeSS — вчитися працювати разом. Ми отримуємо досвід, аналізуємо його та поступово покращуємо організацію роботи. Це колективний процес. Ніхто не знає наперед, як краще щось робити. Це постійні експерименти. Іноді — провальні, але це і є навчання.

Як удосконалили Definition of Done

З переходом на LeSS ми усвідомили, що нам потрібно фокусуватися не тільки на окремих технічних завданнях, які виконують розробники та тестувальники, а на фічі повністю. Але над нею працюють багато інших співробітників. Тож нам довелося змінити підхід до того, як ми працюємо з Definition of Done.

Ми розділили DoD та роботу з ним на чотири блоки:

• Якість коду та тестування. Насамперед сюди відноситься код-рев’ю та покриття коду автотестами. Ми робили це і раніше, але тепер вирішили формалізувати ці процеси. Так, всі нові фічі ми покриватимемо тестами і йтимемо від низькорівневих тестів до високорівневих.
• Внутрішня документація. Тут варто виділити два напрями: для dev-відділу (технічною мовою) та для інших співробітників (у форматі статей, з прикладами, скрінами, відео). Якісний опис фіч та процесів спрощує обмін знаннями: будь-який працівник може зазирнути до тексту та ознайомитися з новим для себе доменом.
• Рев’ю фіч. Ми проводимо окремий дзвінок, у якому збираємо співробітників, які нам потрібні. Наприклад, для рев’ю дизайнів кличемо дизайнера та UX-райтера. Разом з ними рухаємося flow фічі — і виявляємо ті елементи, які могли проґавити. Це можуть бути якісь помилки в дизайні, тексті тощо.
• Нагадування. Це можуть бути певні метрики, розбір якоїсь тестової групи, взаємодії з командою онбордингу. Вони не є обов’язковими для будь-якої задачі, але час від часу можуть знадобитися. Наприклад, хочемо протестувати нову фічу — і маємо у DoD чек-лист, як вибрати відповідну тестову групу.

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

Як проходить робота зі спільним беклогом

Після переходу на LeSS ми отримали одного головного Product Owner та шість Product Managers. Вони розподіляють між собою ініціативи та проблеми. Product Manager збирає інформацію зовні: від розробників, сапорта, фаундера тощо — та перетворює це на високорівневу задачу. Його задача — знайти найважливішу проблему користувачів, розв’язання якої дасть найбільшу цінність для продукту.

Після того, як ідея фічі сформована, Product Manager збирає фідбек клієнтів. Наприклад, ми проводимо так зване коридорне інтерв’ю: спілкуємося з користувачем та оцінюємо, чи розуміє він фічу, чи вирішує вона його проблему, наскільки якісно.

Коли Product Manager опрацював всю інформацію, він готує картку для беклогу та формує для неї Definition of Ready (DoR). При цьому він описує проблему клієнта, а не шлях її розв’язання. У такий спосіб команда залишається самостійною у пошуку та прийнятті рішень.

Потім картка йде на пріоритезацію. Команда Product Managers разом визначає, що ми можемо взяти до Product Backlog Refinement (PBR) та у якому пріоритеті. Вони спілкуються, сперечаються, доводять важливість цінностей — це і є живий процес.

Під час PBR перемішуємо членів команд, і такі змішані групи вирушають до кімнати в Zoom. Там вони разом з Product Managers опрацьовують кілька пов’язаних елементів беклогу.

Також ми кличемо на ці зустрічі всіх тих, хто знає, з чим стикаються користувачі. Наприклад, працівника сапорту, який опрацьовував певні заявки, або співробітника, який проводить онбординг клієнтів. Їхні інсайти дозволяють командам краще зрозуміти цінність нової фічі.

Одне з головних завдань на таких дискусіях — розбивати великий елемент беклогу на кілька дрібніших PBI (Product Backlog Items), які можна брати в роботу. Головне — отримати на виході список задач, щоб розпочати наступний спринт. Загалом витрачаємо 5-7% часу поточного спринту, щоб опрацювати беклог наперед.

Дошка Miro з нашого PBR у грудні

Як команди взаємодіють протягом спринту

Для ефективної комунікації ми застосовуємо декілька практик:

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

Загальний чат. Раніше кожна команда мала свою зону відповідальності та власні окремі чати. Але з переходом на LeSS нам знадобився загальний чат на всіх, а також чати на кілька команд — за доменами.

Наприклад, є чат «РРО (Реєстратор розрахункових операцій)». Коли команда починає робити фічу про касові операції, вона додається до цього чату. У такий спосіб всі причетні мають спільний простір для дискусій. Там обговорюються як технічні речі, так і питання на кшталт: «Привіт, я ніколи не працював з даними та звітами, які ми надсилаємо до податкової при фіскалізації чека. Допоможіть мені!».

Community. Це схоже на чати, але вони збираються під певну мету. Наприклад, спільнота з обговорення Definition of Done, інженерних практик тощо.

Git blame. Наразі у нас немає команди, яка відповідає тільки за щось одне. І ось, коли розробник бачить незнайомий та незрозумілий шматочок коду, то він може подивитися, хто його написав, підійти до цієї людини та попросити допомогу, щоб розібратися в програмуванні цього елемента.

Які складнощі долали в процесі переходу

Процес переходу на LeSS не є простим, але якихось факапів у нас не було. Ключові складнощі пов’язані, напевно, зі стеком технологій. Раніше всі розробники фокусувалися на певних технологіях. Але на LeSS Flip Event ми прийняли тезу, що кожний інженер, у першу чергу, є інженером — незалежно від того, яку технологію та інструменти він звик використовувати.

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

Поступово люди навчилися, здобули експертизу, і швидкість роботи значно зросла. Наразі наші команди не дивляться не технологічний стек, а просто вирішують проблеми клієнтів.

Звісно, ми не можемо прийти до точки, коли всі команди зможуть робити все. Досі є спеціалізації, старі навички та знання мають вагу. Але тепер ми маємо змогу осмислено ухвалювати рішення, яка команда над якою задачею з загального беклогу працює — а не робити це просто тому, що так склалося.

Як змінюються процеси під час війни

Протягом першого тижня після початку повномасштабної війни ми були в анабіозі. Хтось з колег переїжджав або перевозив сім’ї до безпечніших регіонів, тож не всі перебували на зв’язку. Але згодом ситуація трохи стабілізувалася, і ми повернулися до роботи.

В першу чергу скоротили тривалість спринтів: з двох тижнів до одного. Це дозволило більш гнучко керувати беклогом та розв’язати частину проблем з комунікаціями. Наприклад, під час однотижневого спринту і спринт-рев’ю проходить щотижня, тож розробники почали отримувати зворотний зв’язок від продуктової команди вдвічі частіше, ніж раніше.

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

У наших планах — зробити так, щоб прямої комунікації між розробниками та клієнтами було ще більше. Можливо, спробуємо заснувати ком’юніті навколо продукту, щоб об’єднати користувачів, які зацікавлені стати Early Adopters.

Щодо внутрішнього росту, наразі у нас є кілька спільнот, які активно розвиваються. Зокрема — інженери, які займаються тестуванням. Ми вкладаємо багато ресурсів в автоматизацію, проводимо навчання. Більшість наших QA, які раніше займалися виключно Manual-тестуванням, уже пишуть автотести. Це позитивно впливає на якість кінцевого продукту.

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

Також на рівні розробки ми експериментуємо з TDD (Test-Driven Development). Поки що зарано казати про успіхи, але ми рухаємося у цьому напрямі. А LeSS задає зручний фреймворк роботи, щоб працювати та удосконалювати свою експертизу.