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

Привіт! Я Ілля, 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 задає зручний фреймворк роботи, щоб працювати та удосконалювати свою експертизу.

👍ПодобаєтьсяСподобалось23
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Чим замінили Miro?

-

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

У нас дійсно з цим не буває багато проблем. На зараз в одий репозиторій можуть вносити зміни усі члени команди і це не блокує роботу один одному у більшості випадків. Ми багато інвестували в наш CI/CD (і продовжуємо це робити) і це нам дуже допомагає щоб мерж і доставка оновлень проходила як умога гладкіше.

Окремо варто приділити увагу практикам координації які пропонує LeSS: just talk, travellers — ми їх використовуємо постійно, це дуже допомагає. Зараз ми експерементуємо з координаційною практикою leading team яка описана в LeSS

Вітаю з класною трансформацією здорової людини

Красавчики! З радістю спостерігаю за вашими щмінами і досягненнями. Keep going!

Як Постер справляється з тим, щоб нові кросс-функціональні команди не поверталися до фокусування на улубленних задачах,в яких вони розбираються ?

Бо це звично: якщо команда сама обирає топіки в розробку, то вона звикає до своїх тем і не бере в розробку теми сусідів, а отже кросс-функціональна команда скочується, спочатку, до вужчого фокусу, а далі й взагалі до вузької спеціалізації. І на цьому LeSS може скінчитись.

Гарне питання. Команди беруть роботу з єдиного продакт беклогу з глобальними пріорітетами, а не роблять те, що хотять.

Якщо ніхто/ніщо не обмежує вибір тасок з цього єдиного беклогу, то він не страхує від стихійної спеціалізації команд за певними доменами.

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

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

Я теж думав що так буде, але на практиці вийшло не зовсім так. Команди доволі часто самі піднімають тему розширеня спеціалізації на своїх ретроспективах щоб брати PBI з тих тем з якими не працювали, тому що:
1) ми працюємо з беклогом за приорітетом, коли PBI з найвищім приорітетом не взяли, те йде слідом брати не можна, тому ви як команда можете попасти в ситуацію коли іншої роботи окрім як «ось ця» — не може бути, тому що вона найважливіша.
2) рано чи пізно ви як команда попадете в ситуацію коли у вас не буде вибора як брати PBI з тієї компоненти яку ви не знаєете. Тому краще вам як команді підготуватись до цього і стоврити собі певні умови щоб взяти цю роботу в умовах коли ви можете приділити час на занурення і навчання в нову область

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

Скрам — це про крос-функційні фічер-команди, що працюють з продуктами, а не з окремими компонентами. Далі в статті Ви апелюєте до крос-компонентних команд, що наштовхує на думку про ймовірну відсутність зміни парадигми від проектної/компонентної до продуктової.

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

З контексту складно зрозуміти чи компанія пропонує один out of the box продукт, чи портфоліо з декількох продуктів. Якщо Ви ще цього не робили, то щиро раджу виконати Value Stream Mapping і зрозуміти яку насправді кількість незалежних продуктів компанія пропонує клієнтам. На кожен окремий продукт буде потрібен окремий беклог і окремі команди/інженери. Інакше є ризик наступити на ті самі граблі.

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

Чому саме LeSS? Не знайшов у статті пояснення чому обрали саме цей фреймворк.
Чи розглядали Ви Nexus або ж Scrum@Scale?

Також ми вирішили, що будемо вчитися брати менше фіч, але доводити їх до більшої готовності.

Краще беріть ще менше фічерів, але закінчіть їх повністю. Спробуйте порахувати скільки часу йде на ’допилювання’ таких фічерів ’більшої готовності’, які ризики вони в собі несуть.
Definition of Done у Скрам і LeSS — річ бінарна: або щось готове, або не готове. За незавершені речі доведеться платити з відсотками за технічним боргом.

Після переходу на LeSS

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

Романе. Уся ця стаття про орг зміни. Вчитайтеся.

1. Постер пішов від підходу компонентних команд на feature cross-functional cross-component customet-facing команд. Це орг зміна.

2. Постер прибрав позицію team-level product owner. Це дуже важка і суттєва орг зміна. Ці люди знайшли нову роботу всередині Постера. Де-кто з них пішов у команду. Де-кто став продакт менеджером

3. Постер поставив 1 Product Owner. Це СЕО компанії. Це мега орга зміна.

4. Постер перейшов на 1 продакт беклог із цілями замість 10 беклогів з тасками. Це орг зміна.

5. Команди відкрили свої репозиторії одна для одної. Internal open source. Це суттєва орг зміна в інженерній культури.

6. Постер прибрар позицію team lead що була всередені команди. Замість цього ввели позицію Engineering Manager. Це 3-4 людини на компанію. Кожна працює з
2-3 командами. Мета — ростити development capacity команд

І багато чого ще.

Вітольде,

1. На зображенні ’Як ми працбємо зараз’ вказано ’5 крос-КОМПОНЕНТНИХ інженерних команд’, звідси й питання. Зараз ви пишете про крос-функційні крос-компонентні кастомер-фейсинг команди. Навіщо для команд, що вже й так крос-функційні, наголошувати на їх крос-компонентності? Перше визначення є ширшим.

2&3. За що відповідають у вашій моделі новопризначені продакт менеджери, враховуючи, що за єдиний наявний продакт беклог відповідає Product Owner = CEO?

Епіхарію, відповідаю на ваше питання.

1. На зображенні ’Як ми працбємо зараз’ вказано ’5 крос-КОМПОНЕНТНИХ інженерних команд’, звідси й питання. Зараз ви пишете про крос-функційні крос-компонентні кастомер-фейсинг команди. Навіщо для команд, що вже й так крос-функційні, наголошувати на їх крос-компонентності? Перше визначення є ширшим.

Команда може будет кросс-ф і при тому працювати тільки над одним модулем системи — аналізувати, розробляти, тестувати. То є функції команди. Але не кросс-компонентність.

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

В однокомандному Скрамі — де на весь продукт є одна команда, дійсно, ніхто не говорить про крос-компонентність. Але в маштабі — то є сама важка річ.

В матеріалах LeSS є така мапа: https://less.works/less/adoption/feature-team-adoption_map. Там по осі X: кросс-ф, а по осі Y: кросс-комп.

2&3. За що відповідають у вашій моделі новопризначені продакт менеджери, враховуючи, що за єдиний наявний продакт беклог відповідає Product Owner = CEO?

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

Вони також допомагають командам дізнатися деталей елементів беклогу (який пріорітезує PO) та задизайніти гарні фічі.

А як ви бачите роботу PO наодинці? Це нереально.

То вони виконують роль Area Product Owners? Чи радше Subject Matter Experts?

Де Ви побачили щось про роботу PO наодинціі? Те, що PO відповідає за беклог не означає, що він все робить самотужки. Будь-якому РО в масштабованому середовищі доведеться шукати допомоги і багато делегувати.

Вони НЕ працюють, як Area Product Owners — то є тема з LeSS Huge, де 8+ команд, і один PO вже не справляється.

В постері — LeSS. Один на всіх. Один ПО, один Беклог на всі команди.

Продакт менеджери працюють... продакт менеджерами, допомогаючи робити класний продукт. Але вони НЕ володіють беклогами. В деяких речах вони насправді — subject matter experts, деколи вони експерти в product discovery process.

Романе

У Постері на всю компанію — ОДИН продукт. Це теж була зміна. Зміна в розумінні свого продукту.

Тому їм не потрібно робити value stream mapping.

Вітольде,

Value Steam Mapping може не лише дати усвідомлення того, що усі Ваші компоненти насправді формують один єдиний продукт з точки зору клієнта, але й виявити що один чи декілька ваших компонентів можуть служити як окремий продукт, але для іншої цільової аудиторії.

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

Ви неуважно читали статтю, я гадаю.

Value Steam Mapping може не лише дати усвідомлення того, що усі Ваші компоненти насправді формують один єдиний продукт з точки зору клієнта, але й виявити що один чи декілька ваших компонентів можуть служити як окремий продукт, але для іншої цільової аудиторії.

У Постера один продукт. З точки зору широкої дефініції продукту як того, что є enabler of the business model. Та насправді є різні клієнтськи портрети, B2B, B2B2C...

Але ми хотіли прийти до такого широкого розуміння — в нас один продукт. Один на всіх. Ламаємо стіни.

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

Читаємо тут: https://less.works/less/framework/product

Але ми хотіли прийти до такого широкого розуміння — в нас один продукт. Один на всіх. Ламаємо стіни.

І для цього ми використовували системне мислення.

Цього в статті не було, дякую за уточнення.

Стаття як раз про це.

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

Тобто, по суті, Ви переформатували спеціалізованних розробників в інженерів, які можуть взятись за все. Підкажіть, чи були незадоволені (може звільнення) в процессі наскільки успішно тепер проходить найм нових співробітників? Цікаво, що Ви тепер питаєте на співбесіді

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

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

Людей не можна «переформувати». Poster зробив умови, в яких спеціалізовані розробники можуть також розвиватись в шир.

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

Тому мені і цікаво, як Ви оцінюєте людину на співбесіді

Чи розглядали команди інші фреймворки? Якщо так, чому надали перевагу LeSS?

не говорите о фреймворках, говорите об целях оптимизации.. и если это масштабирование разработки продукта по скраму — альтернативы LeSSу не нужно искать

До цього ми більше 5 років розглядали SAFe як модель по якій будемо масштабуватись, але якось не прижилось. В першу через залежності між командами під час планування і відсутності можливості гнучко керувати напрямом куди фокусувати зусилля усієї компанії.

Станіславе

Постер навчив усіх інженерів, менеджерів та С-level системному мисленню та LeSS. Після цього альтернативи не розглядалися.

Чому? Тому ще optimizing goal з LeSS співпав з тим, що було потрібно Постеру. А саме — адаптивність для пошуку цінності та ії постачання.

Навіщо шукати іншу жінку, коли ти закохався?

Підписатись на коментарі