Як зробити ретроспективу спринта ефективною: поради бізнес-аналітика

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

З цієї статті ви дізнаєтесь, як зробити ретроспективу корисною для команди, проєкту і для вас самих.

Ретроспектива — що це?

По суті це аналог рефлексії — природного механізму нашої психіки. Ми всі в тій чи іншій мірі рефлексуємо щодня. Це допомагає аналізувати власні вчинки й уникати помилок у майбутньому. Людям складно повноцінно оцінити ситуацію в моменті, а от рефлексія дозволяє зробити це в спокійній атмосфері. Фактично це є реалізацією методу Plan-Do-Check-Actмодель безперервного поліпшення процесів, цикл PDCA — плануй (Plan), роби (Do), перевіряй (Check), впливай (Act).

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

Ознаки НЕефективної ретроспективи

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

Підготовка до ретроспективи

«Навіщо готуватися, все й так зрозуміло!». Інколи може здатися, що достатньо створити таблицю зі стовпчиками «що вийшло добре», «що погано» і «що покращити».

Але саме підготовка допомагає вирішити декілька викликів:

• Ретроспективи взагалі не відбуваються

На одних проєктах їх ніколи не проводили, на інших — немає Scrum-методології (бо проєкт триватиме кілька місяців). Десь команда не бачить сенсу в додатковому аналізі процесів. Але бізнес-аналітик має показати користь від впровадження ретроспектив. Вам треба проаналізувати процеси та показати шляхи їх покращення. Створіть середовище для комфортного спілкування команди та спільного пошуку рішень. Станьте ініціатором процесу. А це неможливо без підготовки.

• Персональні звинувачення

На деяких проєктах ретроспективи переходять у пошук винних та перекидання відповідальності. Це хибний шлях. Мета ретроспективи — обговорити результати роботи, а не самих людей.

• «Scrum не працює»

Коли чуєте таку фразу від колеги, ви маєте підготуватись особливо ретельно. Визначте, що вони вкладають у цю оцінку та що прагнуть отримати від Scrum-методології. Скоріш за все команда очікує на зміни, які так і не відбуваються. Та проблема може бути не в методі, а в порушенні процесів. Наприклад, команда не прописує Action Items або щось неправильно впроваджує.

• «У нас все і так добре»

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

Проведення ретроспективи

Зазвичай виникає дві проблеми, які знижують ефективність зустрічі:

• Говорять одна-дві людини

Низький рівень залученості позначається на якості рішень. Щоб вся команда впливала на покращення процесів, треба використовувати різні формати та прийоми фасилітації. Спробуйте Round-robin, коли одна людина говорить слідом за іншою, ніби переймає естафету. Так кожен учасник зможе виговоритись і запропонувати ідеї для поліпшення процесів та якості роботи.

• «У нас все добре, а ось вони…»

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

Завершення ретроспективи

Навіть якщо попередні етапи пройшли якісно, все може змінитися у фіналі. Що зазвичай стає причиною?

• Немає Action Items або вони не впроваджуються

Люди збираються на ретроспективу, все обговорюють, але далі нічого не роблять. Мітинг втрачає сенс. Тому фіксуйте і впроваджуйте Action Items (детальніше, як це робити, опишу нижче у статті).

• Нічого не змінюється

Тут причин може бути декілька. Наприклад, ви неправильно працюєте з Action Items чи ставите відповідальними за дії не відповідних фахівців. Розберіть кожну ситуацію та спробуйте знайти доцільне рішення.

Як підготуватися до ретроспективи — основні кроки

• Мета. Вона задає динаміку зустрічі. До початку мітингу ви маєте з командою чітко визначити, навіщо збираєтесь на обговорення.
• Учасники та тривалість зустрічі. Уявімо команду, яка не працює зі Scrum. У цьому випадку ви запрошуєте тих, кого стосуються зміни, які ви будете обговорювати. Подібний мітинг може тривати від 1 до 8 годин. Останнє стосується великих команд. Для таких обговорень існує багато технік, аби все пройшло продуктивно. Наприклад, об’єднуючись у малі групи, шанс бути почутими з’являється. Якщо ви працюєте за Scrum-методологію, то учасники ретроспектив прописані в гайді: команда розробки, Scrum-майстер та Product Owner. Наголошую: ніяких менеджерів! Вони часто хочуть прийти на ретроспективу і вплинути на команду. Це порушення методології. Тривалість таких зустрічей залежить від спринтів. При 4-тижневому спринті це до 3 годин. У моїх проєктах зазвичай 2-тижневі спринти, і ретро тривають до години.
• Формат. Класичний формат передбачає обговорення трьох тем: що було добре, що було погано, що варто поліпшити. Насправді їх безліч, але я зосереджусь на найбільш цікавих для мене.

Ідеї ретроспективи для нещодавно сформованих команд

• One word retro. Учасники одним словом описують минулий спринт чи певний період часу. Завдяки цьому можна легко розговорити людей. Формат добре підходить для першої ретроспективи на проєкті. Таке завдання спонукає замислитися над спринтом, спробувати узагальнити враження та підібрати влучне слово. А це вже стає основою для змістовного обговорення.
• DAKI: Drop, Add, Keep, Improve. Ці слова описують колонки таблиці. В першій — учасники описують, що хочуть прибрати в проєкті, в другій — що додати, в третій — що продовжити робити, а в останній — що покращити.
• 3Ls: Liked, Learned, Lacked. Команда повинна описати, що їй сподобалось, чого вона навчилась і що хотіла б, аби трапилось минулого спринту. Головний плюс цього формату — немає негативної колонки, яку тут замінює Learned. Команди фокусуються на позитивному підході. Цей формат стане в пригоді в особливо складному, трудомісткому спринті, коли люди можуть довго говорити, що було не так.
• Speedcar. Учасники просто перелічують усе, що дозволяє рухатися, та що гальмує проєкт. Подібно до руху машини: щось її прискорює, а щось — зупиняє.

Формати ретроспективи для досвідчених команд

• Scrum retro. Усім знайомий і дійсно ефективний формат навіть без покращень, як в інших схемах. Згадуємо, що відбулось поганого, що було добре і що варто зробити далі.
• 4Ls. Покращений варіант 3Ls, до якого додалось Longed for. У цій колонці учасники описують, що має відбуватися на проєкті в майбутньому. Але для розуміння бажаного розвитку процесів у людей має бути досвід, в ідеалі — з інших проєктів.
• Sailboat. Це метафоричний формат, в межах якого учасники мають уявити себе на кораблі. Дещо подібний до Speedcar, але на додачу до опису того, що команду прискорює (вітер) та гальмує (якір), треба назвати позитивні емоції (сонце) та ризики (рифи). Останнє дозволяє підсвітити потенційні проблеми. Люди дійсно можуть малювати це у вигляді вітрильника та адаптувати під проєкт. У тому ж Miro знайдете багато темплейтів під різні цілі.
• KALM: Keep, Add, Less, More. У відповідних колонках вкажіть: що команда хоче продовжувати робити; що треба додати; чого хочеться робити менше; що команда зробила добре.

Я раджу не зупинятися на цих форматах. Шукайте ті, що краще відповідають вашому проєкту та відгукуються команді. Не варто змінювати техніки просто так, аби змінити. Нові формати на кожній ретроспективи можуть збити команду з пантелику. Проте й використання одного прийому роками — погана практика. Так фокус буде постійно на одних і тих самих деталях. Інколи корисно подивитися на процеси під новим кутом. Ви побачите інсайти — те, що дасть поштовх для розвитку команди.

Як провести ретроспективу

Пропоную організувати процес у кілька етапів:

• Icebreakers. Коли всім треба перемкнутись із буденних тасків на рефлексію. Також потрібен високий рівень емпатії один до одного, щоб обговорення було комфортним і відкритим, без образ. Технік, які дозволяють досягти цього, багато. Я обрала 4 найпростіші Icebreaker:

1. описати одним словом свій настрій — сум, тривогу, захват, натхнення тощо;
2. намалювати, якою твариною учасник вважає себе у спринті;
3. яким напоєм людина була людина у попередньому спринті;
4. happiness radar, за яким учасник показує на шкалі рівень щастя або смутку відносно результатів, процесів, команди.

• Перевірка попередніх Action Items. Пам’ятайте: ретроспективи відбуваються задля змінити на краще. Але якщо ви не перевіряєте результати, в якийсь момент люди перестануть виконувати роботу над помилками. Зустрічі втратять сенс, і жодних покращень не станеться.
• Збір даних. Якщо відчуваєте неготовність команди до розмови або страх сказати зайве в присутності ліда, опитуйте анонімно. Так більше шансів отримати реальні думки. Щодо конкретних прикладів, обмежуся двома, які підходять для будь-якого проєкту:

1. Lessons Learned. Добре підходить для аналізу релізу всього проєкту або якоїсь частини. Намалюйте схему зі шкалами Успіх/Фейл та Планове/Незаплановане. Наповнюєте їх подіями, що відбулися. Це допоможе зрозуміти, що вдалося, що на це вплинуло і що слід не дублювати в наступній ітерації.
2. Thumbs up. Гарна техніка для великих ретроспектив із підбиттям підсумків наприкінці проєкту або за рік. Малюєте квадрати Thumbs up, Thumbs down, New Ideas та Recognition та заповнюєте їх відповідними даними.

• Пошук рішень. Після збору даних треба подумати, як здолати виявлені проблеми. Для цього команда генерує можливі рішення. Технік тут багато: брейнштормінг, п’ять «‎Чому»‎‎, діаграма Ішикави , згаданий вище Round-robin. Детально про кожен метод говорити не буду — це вже теми окремих статей. Але суть однакова: пропонувати ідеї та обговорювати, як вони можуть покращити процеси.
• Вибір ідей. Не завжди навіть хорошу ідею можна втілити у життя. Однак кожну проблему можна вирішити декількома способами. Команда має розглянути можливі варіанти реалізацій різних рішень та розставити пріоритети: що є більш важливим, що зробити легше тощо.

І на завершення…

• Складаємо Action Items. Це дозволить систематизувати ідеї та рішення і додати їх у спринт беклог.
• Визначаємо відповідальних. Action Items повинні мати відповідальних за їх виконання. Люди впроваджуватимуть ці задачі, а ви зможете відстежувати прогрес.
• Збираємо фідбеки. Учасники зустрічі ділиться, що їм сподобалося, що — ні, чого не вистачало. Обмінюються думками, як покращити фасилітацію тощо.
• Дякуємо команді. Не забувайте подякувати колегам за те, що вони прийшли і витратили свій час та сили на ретроспективу. Поясніть, наскільки це корисно для них і для подальшого розвитку проєкту.

Наостанок згадаю цитату з книги «Аліса в країні див». Як на мене, в контексті ретроспективи цей діалог дуже доречний:

— Скажіть, будь ласка, як мені звідси вийти? — запитала Аліса

— А куди ти хочеш потрапити? — відповів Кіт.

— Мені все одно…

— Тоді все одно куди йти.

— Тільки б потрапити куди-небудь, — додала дівчина.

— Куди-небудь ти обов’язково потрапиш, — сказав кіт. — Потрібно тільки достатньо довго йти.

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

У кожного проєкту свої цілі. Десь потрібно швидше вивести продукт на ринок. Тоді неважливі дефекти та покриття тестами — головними є швидка презентація та отримання першого фідбеку. Або це може бути продукт для медицини, де акцент — на зменшенні дефектів до рівня менше 1%. Через це і мета ретроспектив буде різною, і фокус обговорення відрізнятиметься.

Тож завжди пам’ятайте про мету. Саме вона задає процеси. На самому початку роботи визначте ціль для себе і команди. А коли зрозумієте, куди рухайтесь як бізнес-аналітик і куди ведете команду — вам буде значно легше досягти мети.