Scrum of Scrums - оптимальний розвиток команди як основа для масштабування
Що спільного між командним розвитком і скрамом? Вони мають справу з ростом та оптимізацією команд. В основному, перш ніж я масштабую гнучкі методи, команда повинна бути оптимально розвинена. Ви можете побачити, коли команда оптимально розвинена тут або в нашому Стаття в блозі.
Що таке Scrum of Scrums?
Scrum of Scrums - це спосіб масштабування Scrum між багатьма командами і, де це доречно, тренінгами. Інші методи - це, наприклад БЕЗПЕЧНО, LeSS або Нексус.
Скрам зі скрамів особливо успішним, коли всі члени Scrum-команди працюють над досягненням спільної мети, довіряють і поважають один одного та об’єднуються. Це вимагає попереднього розвитку команди.
Вирок
“Достатньо малий, щоб залишатися спритним, і достатньо великий, щоб виконувати важливі завдання в спринті”
ти можеш знати. Тож коли настав час масштабуватися? Який оптимальний розмір команди і що потрібно враховувати при формуванні команди? Чи існують рекомендації щодо розвитку команди?
Перш ніж ми заглибимося в тему, невелике зауваження. Нещодавно у нас в гостях були 11 міжнародних експертів з гнучких методів на вебінарі –, присвяченому питанню: Як правильно масштабувати гнучкі методи?
Результатом став цей фантастичний відеозапис (англійською мовою), в якому розглядаються, наприклад, такі питання:
- Як краще починати: знизу вгору чи зверху вниз?
- Як ви допомагаєте лідерам дійти згоди щодо спільного бачення?
- Як правильно обрати гнучкий фреймворк – і чому це насправді не так важливо?
Моя найтепліша рекомендація: подивіться! Це займе відносно багато часу, але воно варте кожної хвилини.
Спочатку історія про Скрам зі Скрамів
Джефф Сазерленд і Кен Швабер шукали метод, який би дозволив гнучко працювати з кількома командами. Було важливо, щоб не кожен працював поодинці, а щоб усі працювали разом, скоординовано. Це була важлива віха в гнучкій розробці. Джефф Сазерленд також написав про це книгу. “Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies”який з’явився у 2001 році.
Scrum of Scrums та масштабованість гнучких методів з того часу стають все більш поширеними. Але можна сказати, що пандемія COVID-19, ймовірно, дала найбільший поштовх для гнучкої розробки - принаймні, для застосування в інших сферах, ніж розробка програмного забезпечення. В принципі, гнучкі методи завжди можна застосовувати, коли вимоги та технології є складними. The Стейсі Матрикс і Рамкова програма Cynefin допоможуть вам їх класифікувати. На Посібник зі Scrum@Scale ви знайдете всю інформацію про масштабування.
Порада: масштабуватися варто лише тоді, коли ваша команда добре працює разом і функціонує. Якщо у вас вже є проблеми зі Scrum на рівні окремої команди, вам не варто масштабуватися. Моя рекомендація щодо розвитку команди тут: Спочатку розвивайте команду і вирішуйте її проблеми, перш ніж починати масштабування.
До речі, коротка примітка в контексті agile-трансформації: Хочете бути впевнені, що зараз ставите правильні пріоритети у своїй agile-трансформації?
Тоді пройдіть нашу перевірку рівня зрілості для вашої agile-трансформації - це займе лише 3 хвилини. Ви навіть отримаєте еталонний показник на основі понад трьохсот інших учасників. Дивіться кнопку 🙂
Мета скраму зі скрамів
Scrum of Scrum - це перше логічне продовження Scrum при переході від гнучкості в команді до гнучкості всієї компанії. Важливою передумовою для масштабування є правильний склад команди. Необхідно відповісти на наступні питання:
- Хто на якій посаді працює в команді?
- Хто з ким працює?
- Хто особливо добре гармонує разом?
- У кого яка роль?
Ми з’ясували, що чіткий розподіл ролей відіграє дуже важливу роль. До речі: якщо ви хочете дізнатися, які важелі ви можете використовувати для створення інновацій в команді, перегляньте це Відео ан. Командам також завжди потрібно достатньо часу і простору для розвитку. Тут ви також можете завантажити книгу Tuckman’s Поетапна модель розвитку команди щоб познайомитися ближче:
- Формування (фаза входження та відкриття),
- Штурм (фаза суперечки та аргументації)
- Нормування (Нормативно-правова та конвенційна фаза)
- Виконання (фаза роботи та виконання).
Джерело: Модель етапів розвитку команди Tuckman’s
Мета полягає в тому, щоб координувати менші, гнучкі та автономні команди, які повністю зосереджені на потребах і бажаннях клієнтів. Темою клієнтоорієнтованості може бути тут. також люблять розглядати його більш детально. Тому завжди варто зайти на сторінку Подорож клієнта вашого клієнта. Просто будьте своїм клієнтом і почніть змінювати перспективу. На практиці, на жаль, клієнтам все ще доволі часто доводиться пристосовуватися до процесів компанії, з якою вони співпрацюють. Особливо в органах державної влади, але також і в деяких великих компаніях чи корпораціях. Однак це не є ідеєю Scrum.
“Зростання” не те саме, що “масштабування”
Домінік Прайс пише в “Відмова від цих п’яти помилок зробить вас більш інноваційними” про 5 помилкових уявлень, яких слід позбутися, щоб стати більш інноваційним.
- “Зростання” - це не те саме, що “масштабування”.
- “Трансформація” - це не те саме, що “еволюція
- “Тривожний” - це не те саме, що “занепокоєний”.
- “Час відвідування” - це не те саме, що “ініціативність
- “Проміжні результати” не дорівнюють “кінцевим результатам”.
Підсумовуючи, це означає: ефективність - це добре, результативність - ще краще. Завжди звертайте увагу на ефективність.
З досвіду можемо сказати: чим більше людей працює над однією проблемою, тим складніше прийти до рішення. Особливо, якщо це міжфункціональні, автономні члени команди. Однак рішенням для команд, які стають більшими, є масштабування. В рамках проекту “Масштабування Посібник зі скраму забезпечує основу для команд і компаній, які потребують підтримки в цій сфері. Масштабування Scrum за межі окремих команд, однак, вимагає іншого підходу. Техніка Scrum of Scrums (Технологія SoS).
Джерело: Професіонали RFC
Структура та процес Scrum of Scrums
Структура команди Scrum of Scrums
Комунікація - це все і вся в гнучкому світі та ключ до успіху. Чим більша команда, тим швидше страждають канали комунікації. Інформація надходить неправильно або взагалі не надходить. Рано чи пізно це також впливає на довіру в команді, виникає брак близькості і стає складніше досягати спільної мети.
Мета - розвинути команду таким чином, щоб всі перешкоди були усунені (Scrum Master) і саме в Потік працює. Теоретично, “ідеальна команда” з оптимальними показниками за Дослідження Хакмана та Відмара з 4,6 осіб. Занадто малі команди можуть бути недостатніми для вирішення проблеми. У свою чергу, у надто великих командах страждають особисті стосунки та гнучкість щодо здатності клієнта діяти та його інтересів.
У деяких випадках це вимагає поділу команди. Але будьте обережні, тут потрібно враховувати деякі моменти. Ви втручаєтесь у вже створену систему. Компетенції між командами повинні бути розподілені збалансовано, функціональні інтерфейси повинні бути перевизначені, а завдання перерозподілені або перевизначені. Неочікувані залежності та нові вузькі місця можуть затримати процес в цілому. Тут також важливо спілкуватися відкрито і давати команді час і простір. Терпіння і коригування в потрібних місцях також дуже важливі.
Техніка Scrum-of-Scrums вимагає координації, коли формується кілька команд. На наступній схемі показано один із можливих варіантів:
Джерело: Atlassian
Інші ролі в скрамі зі скрамів
Головний власник продукту: Головний власник продукту відповідає за загальне бачення продукту. Він визначає пріоритети в роботі над продуктом і є інтерфейсом і рупором для клієнта.
Майстер Scrum of Scrums: він постійно сприяє підвищенню ефективності Scrum of Scrums. Він фокусується на прогресі та перешкодах, які видно іншим командам, надихає та підтримує команду у виконанні їхніх завдань. Він також Лідер служіння дзвонили.
Зустріч скраму зі скрамів
Члени команди призначають одну особу для участі у зустрічі Scrum of Scrums від імені Scrum-команди. Залежно від того, на чому фокусується проект, команда завжди може призначити іншого представника. Як правило, призначається людина, яка найближче знайома з темою. Якщо фокус на користувацькому досвіді, слід відправити представника, який знайомий з цим. Якщо основна увага приділяється тестуванню, представник повинен бути з області тестування. У деяких випадках, якщо SOS команда стає занадто малою, може бути доцільно, щоб на зустрічі були присутні два представники від команди. Часто Scrum Master буде супроводжувати особу, призначену командою. Якщо робота зустрічей Scrum of Scrums координується на зустрічі на більш високому рівні, це називається Scrum of Scrums meeting.
Періодичність і таймбокс** від Scrum of Scrum Meetings**
Команда визначає частоту зустрічей Scrum of Scrum. Для простоти, ми дотримуємося рекомендацій Scrum of Scrum, які відбуваються щодня і зазвичай тривають максимум 15 хвилин..
Однак, залежно від розміру та кількості команд, дуже часто це більш тривалі зустрічі, які відбуваються не так часто. Наприклад, 2-3 рази на тиждень. На відміну від щоденної зустрічі, проблеми, які виникають на зустрічі Scrum of Scrums, вирішуються безпосередньо, якщо це можливо, або, принаймні, розглядаються. Проблеми, які виникають на цій зустрічі, є дуже значними проблемами і можуть швидко вплинути на більш ніж 100 людей.
Порядок денний зустрічі
Джерело: Вимкнути сплеск
Хороший порядок денний для зустрічі Scrum of Scrums - це порядок денний Щоденні скрами дуже схожі. Оскільки на практиці зустрічі Scrum of Scrums відбуваються не щодня, і оскільки кожна людина представляє на зустрічі всю свою команду, відповіді на питання даються дещо по-іншому:
- Чого досягла ваша команда з часу нашої останньої зустрічі?
- Що ваша команда зробить до наступної зустрічі?
- Чи є перешкоди, які ускладнюють роботу команди?
- Чи може щось з того, що робить ваша команда, стати на заваді іншій команді?
Останнє запитання стосується процесу та можливого впливу на інші команди. Відповідь на це питання може бути дуже корисною. Він розглядає кілька сценаріїв заздалегідь, щоб створити безперешкодну співпрацю. Саме тут фактично руйнується вузькопрофільне мислення. Відповідь на останнє запитання особливо важлива, оскільки вкрай важливо, щоб отримані висновки були передані представниками своїм командам.
Окрім відповідей на запитання, зустріч також надає час і простір для обговорення та вирішення будь-яких питань, проблем або викликів, що виникли раніше. Під час зустрічі документується прогрес і створюється спільне розуміння. Рішення та дії фіксуються, щоб їх можна було відстежувати.
Для того, щоб залишатися на фактологічному та нейтральному рівні, під час обговорення не згадуються жодні імена. Тривалість тем також чітко відмежована від їхньої важливості. Мета полягає в тому, щоб створити об’єктивний погляд з метарівня, але при цьому змінити перспективи.
Висновок
Отже, Scrum of Scrums - це хороший спосіб масштабування, якщо ви вже працюєте зі Scrum і хочете рухатися до гнучкості підприємства. Якщо ви хочете дізнатися більше про оцінку ефективності Scrum Master, будь ласка, також перегляньте ця стаття ан.
Scrum of Scrums та SAFe - дві різні концепції
Scrum of Scrums, SAFe та LeSS - це різні фреймворки для гнучкого масштабування, з різними підходами до впровадження лідерства та побудови дорожньої карти. Якщо ви хочете дізнатися більше про інші концепції, я рекомендую вам прочитати наші статті в блозі БЕЗПЕЧНО і LeSS почитати.
