"Ретро - це зайве": 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 хвилин), тому що таким чином команда дізнається, наскільки важливо може бути інвестувати час. І ви дозволяєте тривалості ретроспективи рости практично “органічно”, через “потяг” або “бажання” команди, тому що в якийсь момент вона захоче більше часу на ретроспективу. Як це зробити? 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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