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

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

Вуді Зуйль

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

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

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

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

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

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

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

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

Якщо ви хочете виміряти рівень гнучкої зрілості –, вам слід використовувати якість ретроспективи як індикатор. Це типова кореляція в часі між "сприйнятою якістю ретроспективи" та "рівнем зрілості Agilem" команди.

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

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

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

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

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

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

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

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

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

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

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

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

Середній показник "повернення інвестицій" за шкалою від 0 до 10 на місяць в інструменті Echometer – Чи варті ретро того? Здається, так!

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

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

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

Іншими словами: В останніх ретроспективах вони, очевидно, "зрозуміли", що ROTI ретроспективної –, тобто якість інвестованого часу, див. вище –, є досить низькою. Існує досить простий підхід, щоб змінити це: просто інвестувати менше часу для того ж результату.

Це, мабуть, найкраща порада, якщо команда вважає, що ретроспектива спринту не потрібна. Скажіть команді: "Гаразд, ми зробимо це якомога коротше" (читайте більше в нашому блозі "Коротка ретроспектива – Краще швидко, ніж ніяк"). 

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

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

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

"Чому нам не вдалося завершити всі історії користувачів, заплановані для останньої ітерації?"

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

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

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

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

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

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

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

 

Що б сталося, наприклад, якби ви пропустили кілька щоденників? Ви знаєте, що станеться? Можливо, це не матиме жодного впливу на – perfect, тоді ви можете залишити все як є і заощадити час. 

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

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

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

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

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

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