"Ретро - це зайве": 7 порад, як реагувати

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

Якщо ви впроваджуєте лише одну практику #agile, це має бути ретроспектива. Все інше буде слідувати.

Вуді Зуйль

Чому ж команда розробників взагалі може вважати ретроспективу спринту зайвою? З мого досвіду скрам-майстра та психолога, це зазвичай пов’язано з рівнем зрілості команди.

Отже, що ви можете зробити, щоб підвищити рівень зрілості вашої команди - в цьому контексті, а також загалом? Ось 7 думок, 7 порад, які допоможуть вам у цьому завданні.

Команда вважає ретроспективу зайвою: що робити?

До речі, офіційна відповідь на сертифікаційному іспиті зі скраму така: Скрам-майстер повинен працювати над командою, щоб зробити її більш ефективною. Хм, це не дуже допомагає. Що це може означати?

Скрам-майстер повинен працювати над командою, щоб зробити її більш ефективною

Офіційна роль Скрам-майстра полягає в наступному, якщо ви подивитеся на Посібник зі скраму дивиться: “Scrum-майстер заохочує Scrum-команду вдосконалювати свій процес розробки та практики в рамках процесу Scrum, щоб зробити його більш ефективним і приємним для наступного спринту.”

В теорії це означає, що ретроспектива має бути центральною подією Scrum-майстра, оскільки головна мета ретроспективи - допомогти команді постійно вдосконалюватися. Однак на практиці команда може не мати достатнього рівня зрілості, щоб по-справжньому використовувати ретроспективу, і тому не бачить її цінності. З цієї причини я особисто інтерпретую твердження “зробити команду більш ефективною” на абстрактному рівні як “підвищити рівень зрілості команди”. Як це зробити в цьому контексті? Перш ніж ми почнемо з порад, ще одне пояснення 🙂

Ретро вважається цінним, коли людина постійно вдосконалюється. Тоді відчуття автономії, самоорганізації та самоефективності є високим. Звідси випливає гіпотеза: Сприйняття якості ретроспективи є одним з найкращих показників рівня (гнучкої) зрілості команди. 

Якщо ви хочете виміряти рівень гнучкості, то якість ретроспектив слід використовувати як показник. Це типовий часовий зв’язок між “сприйнятою якістю ретроспективи” та “гнучким рівнем зрілості” команди.

Ця прогресія досягається наступним чином: 

1. Зроблено перші ретро, записано ноти. Виникає відчуття: нарешті щось відбувається! 
2. Заходи насправді не впроваджуються. Багато розмов, але мало дій. 
3. Через деякий час виникає розчарування або просто так звана “ретро-втома”. Зараз виникає феномен цієї статті: Ретроспектива сприймається як зайва. Сама команда сприймає себе як відносно зрілу і не бачить жодних проблем.
4. Цього етапу досягають лише деякі команди. А саме, коли якість ретро знову зростає, і це врешті-решт призводить до помітних покращень, а отже, повільно дозріває відчуття власної ефективності. 

Сподіваємося, що поради в цьому тексті допоможуть вам зробити кілька кроків у цьому напрямку. Однак, я також можу настійно рекомендувати наш текст про “ 7 порад щодо ефективних заходів %E2%80%9D, які відіграють ще одну роль у цій темі.

1. зрозуміти, чому команда вважає, що ретроспектива не потрібна

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

Часто в команді є “лідер думок”, який має великий вплив на команду. Спробуйте виокремити цю людину, зрозуміти її точку зору і, в кращому випадку, розробити контрзаходи разом з нею (див. нижче).

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

2. провести ретроспективу

Вам слід проводити ретроспективу в будь-якому випадку. Припустимо, команді просто потрібно більше часу, щоб досягти мети спринту - і година кодування замість ретроспективи може мати вирішальне значення. У цьому випадку можна перенести ретроспективу на кілька днів.

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

3. виміряти значення ROTI

Те, що не вимірюється, не може бути змінено. Проста і швидка звичка, яка допоможе вам постійно оцінювати, як команда сприймає ретроспективи, - це вимірювання ROTI-оцінки: значення “повернення інвестицій часу”. Просто задайте наступне питання після кожної ретроспективи, можливо, як перевірку: “За шкалою від 0 до 10, наскільки добре був інвестований час у цю ретроспективу?”. Вимірюйте середнє значення з часом - сподіваюся, ви скоро побачите позитивну тенденцію!

Середній бал “повернення інвестицій часу” за шкалою від 0 до 10 на місяць в інструменті Echometer - чи варті ретроспективи? Схоже на те!

4. зробіть свою ретроспективу спринту дуже короткою

Отже, команда розробників вважає ретроспективу спринту зайвою - що вам, як Scrum-майстру, слід робити зараз?

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

Іншими словами: в останніх ретроспективах вони, очевидно, “дізналися”, що ROTI ретроспективи - тобто якість інвестованого часу, див. вище - досить низька. Існує досить простий підхід, щоб це змінити: просто інвестувати менше часу при тому ж виході 🙂

Це, мабуть, найкраща порада, якщо команда вважає ретроспективу спринту зайвою. Скажіть своїй команді: Добре, ми зробимо її якомога коротшою (більше про це в нашій статті в блозі “ Коротка ретроспектива - краще швидко, ніж взагалі ніяк ”). 

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

Але ви скорочуєте ретроспективу (наприклад, з 60 хвилин до 30 хвилин), тому що таким чином команда дізнається, наскільки важливим може бути інвестування часу. І ви дозволяєте тривалості ретроспективи рости майже “органічно”, через “потяг” або “бажання” команди, тому що в якийсь момент вона захоче більше часу на ретроспективу. Як це зробити? 

Ви просто ставите найважливіше питання:

“Чому нам не вдалося завершити всі призначені для останньої ітерації User Stories?”

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

Ви завжди повинні ставити питання, яке, на вашу думку, викличе хороші думки або дискусії в команді. І ви завжди повинні мати на меті записати експеримент, який ви спробуєте в наступному спринті (також відомий як пункт дій).

5. запропонувати виключити інші процедури

Тож команда вважає, що ретроспектива - це марна трата часу. Гаразд. Як Скрам-майстер, ваша головна мета ніколи не повинна полягати в тому, щоб бути людиною, яка впроваджує Скрам. Ні, справа не в “Скрамі”. 

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

Тож якщо команда незадоволена ретроспективою, ви можете підкреслити, що ви дивитеся на Скрам з точки зору, яку щойно описали. А потім додати, що ви вважаєте, що деякі інші рутини, які у вас є, насправді менш важливі, ніж ретроспектива. 

Ретроспектива - це двигун постійного вдосконалення. Вона покликана допомогти членам команди з’ясувати, що спрацювало добре, а що ні. Якщо ви пропустите цю частину безперервного циклу, ви ризикуєте зупинити цикл безперервного вдосконалення.

Наприклад, що, якби ви пропустили кілька щоденних зустрічей? Чи знаєте ви, що станеться? Можливо, це не матиме жодного впливу - чудово, тоді ви можете залишити все як є і заощадити час. 

З іншого боку, це також може призвести до погіршення комунікації в команді. Через це команда робить помилки. Зрештою, виникне органічна потреба в більшій комунікації, яку ви помітите в ретроспективі. Однак цього разу гнучка церемонія запроваджується не за вашим наполяганням, а через “біль” команди. Як наслідок, ця церемонія буде набагато більш прийнятною для команди.

6. подивіться на минулі ретроспективи та покажіть їхню цінність

Підхід, який може доповнити інші підходи, - це погляд на “Ретроспективну історію” команди за тривалий період часу. Передумовою для цього є те, що деякі з останніх ретроспектив були успішними.

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

Іншими словами: ви усвідомлюєте, наскільки ви покращилися за цей час. Можливо, цей підхід “постійного вдосконалення” все ж може спрацювати?! І ретроспективи могли відіграти в цьому велику роль. При правильному використанні це може призвести до моменту істини в команді.

Крім того, ви також можете подивитися на значення ROTI (рентабельність інвестицій у час) вашої останньої ретроспективи (див. вище): Якщо ви можете довести, що ретроспектива має ROTI від 8 до 10, очевидно, що час було інвестовано добре. Наш інструмент для ретроспективи Echometer, наприклад, запитує ROTI після кожної ретроспективи і таким чином дає вам регулярний показник відповідної ефективності. Ефективність вашої роботи як скрам-майстра .

7. внесіть більше різноманітності у свою ретроспективу

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

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

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

Або ви використовуєте наш інструмент Retro Echometer, який постійно доповнює вашу ретроспективу науково обґрунтованими питаннями. Вони допомагають команді поміркувати над тим, наскільки вона відповідає основним характеристикам успішних команд. Ось приклад одного з питань з нашого інструменту, ще одна передумова для успішних команд - здорова культура зворотного зв’язку:

Я регулярно отримую корисні відгуки про те, наскільки добре я працюю і як я можу вдосконалюватися.

Приклад імпульсу інструменту Echometer, розглянутого в ретроспективі.

Існує багато інших підходів, щоб внести різноманітність у ваші ретроспективи - будьте креативними. 

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

Висновок щодо “зайвих ретроспектив”

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

Насолоджуйтесь своїм 1TP17Continuous Improvement!