Мета скраму зі скрамів

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

• Хто на якій посаді працює в команді?
• Хто з ким працює?
• Хто особливо добре гармонує разом?
• У кого яка роль?

Ми з'ясували, що чіткий розподіл ролей відіграє дуже важливу роль. До речі: якщо ви хочете дізнатися, які важелі ви можете використовувати для створення інновацій в команді, перегляньте це Відео ан. Командам також завжди потрібно достатньо часу і простору для розвитку. Тут ви також можете завантажити книгу Tuckman's Поетапна модель розвитку команди щоб познайомитися ближче: 

1. Формування (фаза входження та відкриття),
2. Штурм (фаза суперечки та аргументації)
3. Нормування (Нормативно-правова та конвенційна фаза)
4. Виконання (фаза роботи та виконання).

Джерело: Фазова модель розвитку команди за Такманом

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

 

"Зростання" - це не те саме, що "масштабування".

Домінік Прайс пише у статті "Відмова від цих п'яти помилок зробить вас більш інноваційними" про 5 помилок, від яких ви повинні звільнитися, щоб стати більш інноваційними.

1. "Зростання" - це не те саме, що "масштабування".
2. "Трансформація" - це не те саме, що "еволюція
3. "Тривожний" - це не те саме, що "занепокоєний". 
4. "Час відвідування" - це не те саме, що "ініціативність 
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, будь ласка, також перегляньте ця стаття ан.