Чому ми наполягаємо на тому, щоб всі команди проводили ретроспективи
Найбільш важлива річ щодо ретроспектив - це їх проведення.
З різних причин команди не виявляють належного інтересу до проведення ретроспектив. Без невеликого тиску з боку багато команд часто пропускають ретроспективу і відразу переходять до наступного спринту. Може бути, це особливість шведського менталітету, в чому я не впевнений.
Хоча при цьому все начебто погоджуються, що ретроспективи вкрай корисні. Я б навіть сказав, що ретроспектива є другим за значимістю заходом в Scrum'e (перше - це планування спринту), тому що це самий підходящий момент для початку поліпшень!
Звичайно, щоб виникла гарна ідея, вам не потрібна ретроспектива, вона може прийти до вас в голову, коли ви вдома в душовій кабінці! Але чи підтримає команда вашу ідею? Може бути, але ймовірність значно вище, якщо ідея народжується всередині команди, тобто, під час ретроспективи, коли кожен може зробити свій внесок в обговорення ідеї.
Без ретроспектив ви виявите, що команда наступає на одні і ті ж граблі знову і знову.
Як ми проводимо ретроспективи
Хоча основний формат трохи варіюється, але в основному ми робимо так:
• Виділяємо 1-3 години, в залежності від того наскільки довга очікується дискусія.
• Беруть участь: product owner, вся команда і я власною персоною.
• Розташовуємося або в окремій кімнаті з затишним м'яким куточком, або на терасі, або в якомусь іншому схожому місці, оскільки нам подобається вести дискусію в спокійній і невимушеній атмосфері.
• Найчастіше ми намагаємося не проводити ретроспективи в робочій кімнаті, так як це розсіює увагу учасників.
• Вибираємо когось в якості секретаря.
• ScrumMaster показує sprint backlog і за участю команди підводить підсумки спринту. Важливі події, висновки і т. Д.
• Починаємо «серію» обговорень. У цей момент кожен має шанс висловитися про те, що, на його думку, було хорошого, що можна було б поліпшити і що б він зробив по-іншому в наступному спринті. При цьому його ніхто не перебиває.
• Ми порівнюємо прогнозовану і реальну продуктивність. Якщо є істотні розбіжності, то намагаємося проаналізувати і зрозуміти, чому так вийшло.
• Коли час добігає кінця, ScrumMaster намагається узагальнити всі конкретні пропозиції з приводу того, що ми можемо поліпшити в наступному спринті.
Ось вам приклад дошки з нашої останньої ретроспективи:
Взагалі-то, наші ретроспективи не мають чіткого плану проведення, але головна тема - завжди одна і та ж: «Що ми можемо поліпшити в наступному спринті». У нас є три колонки:
Добре: Якщо потрібно було б повторити цей спринт ще раз, то ми б зробили це точно так же.
Могло б бути і краще: Якщо потрібно було б повторити цей спринт ще раз, то ми б зробили це по-іншому.
Покращення: Конкретні ідеї про те, як в майбутньому можна щось поліпшити.
Таким чином, перша і друга колонки відноситься до минулого, тоді як третя - спрямована в майбутнє.
Після того як команда закінчив свій мозковий штурм з приводу всіх цих стікерів, вони проводять «точкове голосування» для визначення поліпшень, яким слід приділити особливу увагу в ході наступного спринту. У кожного члена команди є три магнітика, якими він може скористатися для голосування. Кожен член команди може ліпити магнітики як йому заманеться, хоч все три відразу на одну завдання.
Грунтуючись на цьому голосуванні, ми вибираємо 5 поліпшень, які ми спробуємо впровадити в наступному спринті, а на наступній ретроспективі ми перевіримо, що у нас вийшло.
Дуже важливо не переоцінити свої можливості. Виберіть всього кілька поліпшень для наступного спринту.
Як вчитися на чужих помилках
Інформація, яка спливає в ході ретроспектив, зазвичай вкрай важлива. Для команди настали нелегкі часи, тому що менеджери з продажу почали забирати програмістів з роботи на свої зустрічі, щоб ті грали роль «технічних експертів»? Це дуже важлива інформація. Можливо, що і у інших команд точно такі ж проблеми. Може бути, нам варто провести спеціальні тренінги по нашого продукту для відділу маркетингу, щоб вони самостійно змогли відповідати на всі питання клієнтів?
Можливі шляхи вирішення проблем, знайдених командою на ретроспективі, можуть виявитися корисними не тільки для неї самої, а й для інших.
Як же зібрати всі ці результати? Ми вибрали досить простий спосіб. Одна людина (в цьому випадку я) бере участь у всіх ретроспективах в ролі «сполучної ланки». Без всяких формальностей.
В якості альтернативного варіанту можна запропонувати кожній команді складати звіт про проведену ретроспективі. Ми пробували і цей спосіб, але зрозуміли, що не всі читають такі звіти, а ще менше тих, хто роблять висновки з прочитаного. Тому ми зупинилися на найпростіший спосіб.
Найбільш важливі вимоги для людини, який буде «сполучною ланкою»:
• Він повинен бути гарним слухачем.
• Якщо ретроспектива проходить дуже мляво, він повинен бути готовий поставити просте, але влучний питання, який підштовхне людей на дискусію. Наприклад: «Якби можна було повернути час назад і переробити цей спринт з самого першого дня, щоб ви зробили по-іншому?».
• Він повинен бути згоден витрачати свій час на відвідування всіх ретроспектив всіх команд.
• Він повинен володіти необхідними повноваженнями, які допомогли б йому взятися за виконання запропонованих командою поліпшень, що виходять за межі можливостей самої команди.
Такий підхід працює досить добре, але це не означає, що немає підходів набагато краще. Як тільки знайдете щось новеньке, дайте мені знати.
Зміни. Бути чи не бути
Припустимо, команда прийшла до висновку, що «ми дуже слабо спілкувалися всередині команди, тому ми постійно заважали один одному і переробляли архітектурні рішення».
Що нам з цим робити? Організувати щоденні зустрічі для обговорення архітектури? Впровадити нові засоби, щоб спростити спілкування? Створити більше сторінок в wiki? Може, і так. А може й ні.
Приклад, наведений вище ( «ми так слабо спілкувалися всередині команди ...») - це класичний приклад того, що вирішується найкраще бездіяльністю.
Якщо у відповідь на кожну скаргу намагатися щось робити, народ з небажанням буде розповідати про свої навіть найдрібніші проблеми, які можуть бути жахливими.
Типові проблеми, які обговорюють на ретроспективах
У цьому розділі я постараюся описати стандартні проблеми, які спливають в ході ретроспектив, і можливі шляхи їх вирішення.
«Нам треба було більше часу витратити на розбиття історій на підзадачі»
О, це класика жанру. Кожен день на Scrum'е можна почути, як люди вимовляють заяложену до болю фразу: «Я не знаю, що мені сьогодні робити». І вам доводиться день у день витрачати купу часу для того, щоб після Scrum'а знайти завдання для цих хлопців. Моя порада - робіть це заздалегідь.
Стандартні дії: ніяких. Можливо, команда сама вирішить цю проблему на наступному плануванні. Якщо ж це повторюється з разу в раз, збільште час на планування спринту.
«Дуже часто турбують ззовні»
• Попросіть команду зменшити фокус-фактор на наступний спринт, щоб у них був більш реалістичний план.
• Попросіть команду більш докладно записувати випадки втручання (хто і як довго). Потім буде легше вирішити проблему.
• Попросіть команду переводити все зовнішні запити на ScrumMaster'а або Product owner'а.
• Попросіть команду вибрати одну людину в якості «голкіпера» і перенаправляти на нього всі питання, які можуть відвернути команду від роботи. Це дозволить решти команди
• сконцентруватися на своїх завданнях. У цей ролі може виступати, як ScrumMaster, так і будь-який член команди, якого потрібно буде періодично міняти.
«Ми взяли величезний шматок роботи, а закінчили лише половину»
Стандартні дії: ніяких. Швидше за все, наступного разу команда не стане братися за нереальний обсяг робіт. Або, принаймні, скромніше оцінить свої можливості.
«У нас в офісі бардак і дуже шумно»
• Спробуйте створити більш сприятливу атмосферу або перевезіть команду на інше місце. Куди завгодно. Можете зняти кімнату в готелі (див. Стор. 43 «Як ми облаштували кімнату команди»).
• Якщо це можливо, попросіть команду зменшити фокус-фактор на наступний спринт з чітким описом причини: шум і бардак в офісі. Може бути, це змусить Product owner'а почати штовхати вищестоящий менеджмент щодо вашої проблеми.
Слава Богу, мені ніколи не доводилося перевозити команду в інше місце. Але якщо доведеться - я це зроблю.: O)