Інсайти з Large-Scale Scrum
Концепт масштабованого Скраму від LeSS Лармана і Водде сповнений простої (часто неінтуітивної) мудрості в стилі Lean.
Нижче — кілька інсайтів з тренінгу Certified LeSS Practitioner від Сезаріо Рамоса:
1. Про ієрархічну орг. структуру
Звідки взялась ієрархічна структура в бізнесі? Після масштабної залізничної аварії на Western Railroad 5 жовтня 1841 року, керівництво залізниці прийняло міри, щоб в майбутньому уникнути ризику проектування і реалізації залізничних шляхів завдяки “загальноприйнятій мудрості домінуючої групи”. Таким чином, бізнес вперше запозичив у армії та церкви ієрархічну структуру, яка при тому управлялась професійними фул-тайм менеджерами, і яка стала прототипом для організаційних структур на наступні століття.
З часом, на початку 1900-их, завдяки Тейлору і Форду на допомогу бізнесу прийшов концепт наукового менеджменту і розподілу праці. Тобто, роз”єднати голову (професійний менеджмент) і руки (робочих без освіти) у тій-таки ієрархії. Звідси пішли і КРІ, які по суті є нормативами для рутинних повторюваних операцій, і не завжди добре працюють для праці інтелектуальної.
Під що оптимізована така структура? Під повторення типових операцій, уникнення помилок та швидкий пошук винних. Під що ви хочете оптимізувати свою організацію? Якщо під швидкість, інноваційність, креативність та навчабельність команд, то ієрархія — не ваш вибір. Скорше — мережа empowered і незалежних команд.
2. Про управління залежностями
Менеджери і команди часто питають — як управляти (міжкомандними) залежностями. Так-от, сприймайте слово “залежність” як щось, протилежне “відповідальності”. Адже коли кажемо “моя задача не рухається, бо у мене — залежність від Команди А”, ми тим самим звільняємо себе від відповідальності вирішити цю залежність. Тому сприймайте залежності як можливість попрацювати разом (наприклад, з кимось із команди А).
3. Про крос-функціональні feature-команди
Якщо ми передаємо роботу з команди А до команди Б (з причин некомпетентності команди А в певних питаннях), команда А так ніколи і не навчиться, і не покращиться. Якщо у вашому контексті/продукті має сенс крос-продуктова навчабельність команд/людей, ваш шлях — крос-функціональні feature-команди. Тобто такі, які можуть “запилити” фічу, що зачіпає будь-який компонент продукта.
При цьому, важливо розуміти, що feature-команда — річ не бінарна. Тобто, в процесі оволодівання знаннями різних компонентів продукта, ваші команди з компонентних перетворюються на фіче-команди.
4. Командна сутність чи командне его?
Більшість із нас звикли, що team entity, чи “індивідуальна командна сутність” — це класно. Командам придмуються назви, вони придумують свої домовленості та правила гри, і завдяки ним — зростають.
Однак, в контексті ширшого поняття продукту чи організації, оптимізованої під його розробку, індивідуальний командний дух може блокувати команду від взаємодії з іншими командами/відділами. Це може статись, коли командна сутність перетворюється в командне его (“Ми в цій організації— найкраща команда. Погляньте на наші результати і корпоративні нагороди!”). А надмірне его, як відомо — є причиною більшості факапів (не лише в бізнесі).
5. Ще два добиваючі інсайти
5.1. If you do the wrong thing right, you are becoming even wronger :) Тобто, якщо ви робите правильно неправильні речі, ви стаєте ще більш неправим. Тобто, рухаєтесь з вищою швидкістю у невірному напрямку…
5.2. Про взаємодію бізнесу з ІТ і time-to-market. Чомусь нікого не хвилює, як довго вимоги до продукта перебувають на стороні бізнес-замовника (збір, формулювання, деталізація), але як тільки формалізовані вимоги потрапляють в ІТ-розробку, дедлайн різко стає актуальним, і всі навколо починають нагнітати тиск на цю тему :)
Keep calm, і пам”ятаймо, що scaled scrum is still scrum!
Найближчим часом попрацюємо над організаційним дизайном та масштабуванням аджайлу в організаціях на курсі Organization Design в бізнес-школі CAPSchool 15–16 березня! До зустрічі!
