Ретроспектива спринту у Scrum

Відомий американський винахідник Томас Едісон винайшов лампочку 140 років тому. Правильніше буде сказати, що він першим зробив лампочку такою, якою ми її знаємо. Для досягнення цієї мети Едісон знадобилося провести близько 2-х тисяч різних експериментів, і врешті-решт йому це вдалося.

Не подумайте, що ця стаття буде про винахід лампочки. Йтиметься про Scrum, а точніше про одну з подій Scrum — ретроспективу спринту.

Я хотів підкреслити, наскільки важливо у будь-якій справі вдосконалюватися, розвиватися та застосовувати нові підходи. У цьому полягає суть ретроспективи спринту, оскільки ця подія, згідно Scrum Guide, має дві мети:

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

Під час ретроспективи команді необхідно виявити та обговорити:

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

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

Варто зазначити, що для спринту тривалістю 1 місяць ретроспектива не повинна перевищувати 3 години, вона проводиться наприкінці спринту перед плануванням наступного. На плануванні важливо врахувати інформацію із двох попередніх подій: переглянутий беклог продукту та покращення, які може використовувати команда у своїй роботі.

У ретро бере участь вся команда Scrum — команда розробки, Product Owner і Scrum майстер.

• Команда розробки займається створенням продукту, і тільки їй належить беклог спринту – список завдань, які команда бере у спринт
• Product Owner відповідає за досягнення максимальної цінності продукту і це єдина людина, яка несе відповідальність за беклог продукту, список завдань з вимогами до продукту.
• Scrum майстер несе відповідальність за просування та підтримку Scrum відповідно до посібника з системи

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

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

1. Організація процесу групової роботи, спрямовану досягнення цілей, поставлених перед групою
2. Модератор або фасилітатор веде групу відповідно до складеного чіткого плану, внаслідок чого учасники повинні досягти необхідного результату, зрозумілого всім і прийнятого кожним із них.
3. І модератор, і фасилітатор не повинні впливати на кінцевий продукт обговорення та нав'язувати свою думку

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

Модератор стримує групу у якихось рамках і дає дискусії втратити суть, а фасилітатор дає більше свободи дій команді, сприяючи її груповий роботі. Модератор системно та структуровано веде групу до бажаного результату. Фасилітатор допомагає групі дійти результату, спираючись власний досвід учасників, підводячи учасників дискусії до важливим, але неочевидним рішенням. Для Scrum Майстра при проведенні ретро важливо знайти золоту середину – сприяти групою роботі команді та не дати команді вийти за межі дискусії.

Щоб ретроспективи були корисними та цікавими, Scrum майстру необхідно до них ретельно готуватися. Для підготовки до проведення ретро Scrum майстру необхідно мати свій чек аркуш, який допоможе не забути і не проґавити важливі моменти. Нижче наведено приклад такого чек аркуша:

1. Яка тривалість ретроспективи? Scrum майстер стежить за лімітом часу, щоб ретро було не надто затягнутим.
2. Де можна знайти результати минулої ретроспективи? Вони повинні десь фіксуватися, щоб Scrum майстер міг перевірити їх разом із командою.
3. Чи враховано зворотній зв'язок щодо покращення ретроспектив? Важливо отримувати фідбек від команди, як пройшла ретроспектива.
4. Які завдання Scrum майстер мав виконати за наслідками минулого ретро? Якщо майстер обіцяв щось зробити, необхідно розповісти про статус цих завдань.
5. Які суттєві події були протягом спринту? Якщо були якісь дуже важливі події, важливо сфокусуватися на цьому в першу чергу.
6. Чи існує важлива тема, якій варто приділити достатньо часу протягом ретро? Можливо, команда планує використовувати нові технології для свого продукту, у такому разі необхідно врахувати всі ризики та продумати подальші кроки.
7. Яку інформацію потрібно підготувати для проведення ретро? Наприклад, якщо Scrum майстер буде застосовувати нові техніки, то важливо продумати, що він візуалізуватиме і показуватиме.
8. Які канцтовари потрібно взяти на ретроспективу? Необхідно врахувати, які канцтовари можуть знадобитися під час ретро (стікери, ручки, маркери, папір, скотч, фотки тощо)

Рекомендуємо курс на тему

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

Насамперед, можна розбити ретро кілька етапів і застосовувати кожному етапі різні техніки для організації груповий роботи з командой.

Хочу звернути вашу увагу, що ці етапи — не аксіома. У Scrum Guide сказано, що можна використовувати різні техніки та підходи в рамках Scrum, зберігаючи його основні положення, зміни лише вітаються.

Отже, про етапи. Спринт ретроспективу подумки можна розбити на 5 етапів:

1. Підготовка. На цьому етапі потрібно розворушити команду та підготувати її для подальшої дискусії.
2. Збір даних. Команда збирає інформацію про те, що пройшло добре у спринті, а де є проблеми
3. генерація ідей. Учасники накидають свої ідеї про те, як можна усунути проблеми та покращити командні дії
4. Планування рішень.Після того, як всі ідеї озвучені, команда вибирає найбільш актуальні з них та обговорює їхнє втілення.
5. Завершення. Наприкінці зустрічі підбиваються підсумки

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

Ітимемо по порядку і почнемо з етапу «Підготовка», її можна провести наступним чином:

1. Location. Для проведення цієї вправи знадобиться якийсь предмет, наприклад стілець. Scrum майстер ставить стілець у центрі кімнати та попросить команду уявити, що це стілець – це мета спринту. Після цього він кожен учасник розташовується по відношенню до стільця на близькій відстані, якщо людина вважає, що ціль виконана, і на дальній, якщо вона не виконана. Після цього можна попросити кожного прокоментувати своє розташування. Варто зазначити, що питання команді можуть бути різні.
2. Гра в Асоціації. Scrum Майстер просить команду описати спринт одним словом. Можна запропонувати порівняти його з погодою чи машиною. За емоціями учасників зустрічі та їх асоціаціями буде зрозуміло, наскільки спринт був вдалим. Наприклад, хтось скаже, що спринт нагадує стару дев'ятку, біля якої двері відвалилися в середині спринту, але потім удалося її прикрутити. Потім ця інформація буде детально розглянута учасниками на наступних етапах, а саме чому це сталося і що зробити, щоб такого не було в майбутньому.
3. Mad, Sad, Glad. Ці три слова необхідно написати на фліпчарті чи борді, і команда по колу ділиться своїми почуттями, які відповідають цим словам.Краще не використовувати цю вправу часто, тому що можна виплеснути багато негативних емоцій.

Переходимо до наступного етапу - "Збір даних". Тут необхідно згадати першу з двох цілей ретроспективи — інспекція, спрямована на себе стосовно людей, взаємин, процесів та інструментів, тобто нам необхідно зібрати дані про те, як ми працюємо. Давайте розглянемо техніки, які можна використовувати на даному етапі.

1. Proud, thank you, learned. Дуже гарна вправа, яку слід проводити частіше. Необхідно розділити дошку на 3 частини та написати: Proud, thank you, learned. Після чого Scrum майстер просить команду написати на стікерах відповіді на такі запитання: «Чим кожен член команди пишається?», «Кому хоче подякувати?», «Чому навчився за спринт?», учасники клеять стікер на одну з 3-х частин, якій відповідає наклейка, і коментують написане.
2. Timeline. Ця активність допоможе відновити у пам'яті події минулого спринту. Необхідно намалювати тимчасову лінію на борді, кожен учасник відновлює у пам'яті всі важливі події, записує подію на стікері та клеїть її на лінію, коротко розповідаючи про неї. Коли команда відтворить усю картину спринту, то у неї з'явиться гарний набір даних перед наступним етапом – «Генерація ідей».
3. Перевірка ДЗ. Назва цієї техніки говорить сама за себе. Усі пункти, які команда погодила до виконання на минулій ретроспективі, потрібно перевірити. Які з пунктів виконані чи застосовуються? А які ще належить застосувати у майбутньому? Для фіксації результатів ретроспективи підійде будь-який зручний інструмент.

Після того, як усі дані зібрані, можна перейти до етапу "Генерація ідей".

На цьому етапі можна застосовувати такі техніки:

1. Continue, Start, Stop. Потрібно поділити борд на 3 частини. У кожній частині пишемо одне з трьох слів - Продовжувати, Почати, Припинити. Учасники пишуть, що команді варто продовжувати робити, що варто почати робити, а взагалі варто перестати робити. Одна ідея – один стікер. Кожен учасник клеїть свій стікер на відповідну частину дошки та коментує свої ідеї. Можна об'єднати схожі ідеї на кластери. Коли команда матиме кілька ідей, учасники зустрічі можуть проголосувати, які з них найважливіші та вимагають негайного виконання. Цю техніку Scrum майстер може змінювати, змінивши три слова. Наприклад він може написати - "Більше, Менше, Перестати" або "Перестати, Почати, Спробувати".
2. Brainstorm. Для цієї активності знадобиться звичайний аркуш паперу та ручки для всіх членів команди. Кожен по черзі пише одну свою ідею щодо покращення роботи команди та передає лист сусідові по колу. Аркуш передається доти, доки у команди не вичерпаються ідеї або не вийде встановлений час. Після того, як усі ідеї записані, їх озвучують усій команді.
3. Sailboat. Scrum майстер малює човен і просить уявити учасників зустрічі, що це їхня команда. Потім він малює якір і пояснює команді, що це те, що тягне її вниз. Потім він зображує вітрила – те, що штовхає команду вперед. Також можна намалювати скелі та рифи (ризики) або обрій (наші надії). Кожен член команди заповнює малюнок стікерами, після чого команда обговорює всі викладені думки та фіксує свої ідеї щодо покращення робочого процесу. Цю техніку можна трохи змінити та провести в іншому вигляді. Замість вітрильника можна використовувати повітряну кулю або гоночний болід із перешкодами.Слід зазначити, що цю активність можна застосовувати на попередньому етапі, оскільки ця вправа включає частину дій зі збору даних командою.

Отже, команда озвучила всі свої думки та ідеї. Тепер настав час для етапу «Планування рішень». Давайте розглянемо техніки, які нам можуть допомогти у цьому:

1. Dot voting. Якщо команда озвучила багато ідей, то необхідно вибрати найбільш актуальні та важливі з них, оскільки неможливо вирішити всі проблеми одразу. Для цього Scrum майстер просить уявити, що у кожного члена команди є 3 уявні точки, ними необхідно проголосувати за три найважливіші ідеї. Ідеї, які зберуть найбільшу кількість голосів, будуть переведені в статус «Action Points» і мають бути виконані в майбутньому.
2. Дебати. Після проставлення пріоритетів можна розбити команду на частини та обговорити ідеї у невеликих групах. Це варто робити лише тоді, коли у вас досить багато учасників дискусії, або частина команди знаходиться в іншому офісі, та проводяться кілька ретроспектив. Після обговорення учасники зустрічі діляться своїми думками. Також можна попросити команду влаштувати дебати між групами, в результаті яких мають бути узгоджені спільні рішення.
3. Top list. Ця вправа також варто використовувати після пріоритезації ідей команди. Потрібно взяти найактуальніші теми та обговорити кожну ідею послідовно.

На останньому завершальному етапі ретроспективи спринту важливо підбити підсумки цієї події. Повинні бути сформовані Action Points — це пункти, які команда домовилася застосувати у роботі для досягнення прогресу. Команда після ретро повинна залишитися натхненною та мотивованою, щоб продовжувати впроваджувати покращення.

На завершальному етапі можна провести так звану «Ретроспективу ретроспективи», тобто отримати зворотний зв'язок Scrum майстром від решти команди. Для цього можна попросити учасників зустрічі написати на стікерах їхні відгуки про ретроспективу з пропозиціями. Scrum майстер враховуватиме цю інформацію при проведенні майбутніх ретроспектив. Замість відгуків на стікерах, майстер Scrum може також отримати фідбек від команди, провівши анкетування.

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

Якщо хочете стати Project manager, курси – ефективний спосіб дізнатися про професію та набути практичних навичок.

Ретроспектива за кроками. Рецепт

Всі, хто чув про Scrum, швидше за все чули про його основні заходи: планування, п'ятихвилинка (stand-up), огляд спринту та ретроспектива. Багато хто чув, інструментів для проведення ретроспектив багато, "навчальних" матеріалів ще більше, але все якось не виходить. Або начебто виходить, але чомусь команда не хоче в цьому брати участь. У цій статті я представлю свій рецепт проведення ретроспектив, не лише представивши конкретні та детальні кроки, а й спробувавши пояснити, чому саме такі кроки й у такому формулюванні.

Хто присутній

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

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

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

У майбутньому проведення (фасилітацію) ретро можна передати члену команди, а через деякий час вибирати нового фасилітатора кожного нового ретро.

Коли

Ретроспектива має проводитися регулярно. Взагалі все в Scrum має робитися регулярно. І планування, і огляд, і ретро. "Сила" методології саме в тому, щоб перетворити непередбачуваний творчий процес розробки на передбачуваний та запланований.

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

Що потрібно для ретро?

Якщо ретро проводиться в "реальному світі", знадобляться стікери/листочки (по 6-10 штук на людину), ручки та дошка з маркером.

У "віртуальному" світі достатньо обійтися розшарованим екраном із двома/трьома блокнотами, або одним екраном Confluence/MS Word із трьома полями. Умовно їх поки що можна назвати "плюси", "мінуси" та "дії".

Для цілей гейміфікації можна використовувати онлайн-інструменти типу fun retro / easy retro, але поки що жоден з цих інструментів не вписався в рецепт, який буде описаний нижче.

Будучи хорошим начальником (або плануючи ним стати) - принесіть на ретро горішків, цукерок, печінок (закадрове дихання *), заплануйте загальний ланч з піцою без відриву від "виробництва".

Початок ретро

На початку всім учасникам команди лунає завдання. Потрібно придумати і записати (поки що в таємниці від інших членів команди – це важливо):

(+) Не менш N таких речей, які їм сподобалися в поточному спринті, і які вони не хотіли б втрачати в процесі ретро змін, що пропонуються в рамках.

(-) Не більше N таких речей, які не подобаються, і хотілося б змінити.

Не потрібно намагатися "оптимізувати" процес і просити членів команди записати ці пункти заздалегідь як домашнє завдання.Все одно їм доведеться на це витрачати час, правда? Нехай краще витратить його все відразу в одному місці, не мучившись докорами сумління за незроблену домашню роботу і без бентежних поглядів колег, які були такими чудовими, що зробили заздалегідь (читай - за 5 хвилин до зустрічі, відволікаючись від якоїсь нудної щотижневої зустрічі). ).

Спочатку про "плюси". Цей пункт важливий хоча б для закріплення того, що команда зробила добре. Похвалити самих себе – теж важливо. Напевно, це підтвердить будь-який психолог. Кордон знизу тут потрібна, щоб кожен член команди змусив себе, по-перше, згадати спринт, що пройшов, а, по-друге, включився таким чином в ретроспективу. "Не хочемо втрачати" - це важлива підказка. Наприклад, вона відразу набрякає такі речі, які не залежать від команди. Немає сенсу обговорювати можливість дистанційної роботи, якщо не команда вирішує це питання. Або є сенс згадати, як подобається поточний CI та швидке проходження ревью, адже саме від команди (зазвичай) він і залежить.

Інше важливе призначення "+"-пунктів, це можливість пізніше, коли пропонуватимуться дії щодо вирішення проблем (action point'и), вибирати ті з них, які мінімальним чином впливатимуть на те, що команда не хоче втратити.

Важливо, щоб плюси та мінуси записувалися на листочках незалежно один від одного. Тим самим ми позбавляємося "проблеми +1", коли люди замість роздумів над проблемою просто приєднуються до чужої відповіді (аналогічна ситуація відбувається, наприклад, при плануванні, від чого захищає "сліпе" покер-планування).

Мінуси. В ідеалі потрібно, щоб учасники одразу записали що їм не подобається.Чи не action point, не те, що вони пропонують зробити, а те, що їм безпосередньо заважає в роботі. Але в принципі на перші 4-6 ретроспективів достатньо, щоб учасники хоч щось записали. А далі ведучий вже витягне з них всю правду (диявольський сміх за кадром).

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

Аналіз

Починаємо із плюсів. Тут можна просто виписати їх у першу колонку (наклеїти стікери), при можливості згрупувавши їх для зручності спостереження і гарного уявлення вищому начальству. Просто поки що пам'ятайте, що ці плюси - це те, що ваша команда хоче зберегти хоча б на наступний спринт і не втратити при виконанні action point'ів.

Мінуси. Найскладніший етап. Гра в лікаря "навпаки".

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

Ще раз. Кожен пункт треба записати у вигляді симптому, а не хвороби (і точно не у вигляді action point'а). Наприклад. Член команди записує на стікеріу нас неоптимальний CI-скрипт".Якщо залишити такий, єдиним можливим способом вирішення цієї проблеми буде, очевидно, переписати CI-скрипт. Але чи потрібно?

Уточнюємо у члена команди, "[Олег], на що у твоїй роботі впливає те, що CI-скрипт не є оптимальним"? Раптом виявляється, що:

• скрипт повільно працює
  • повільна робота призводить до повільного проходження pull request'ів
    • неможливість розпарралелити роботу призводить до простою
      • це призводить до повільної роботи члена команди
      • це призводить до необхідності ручного перезапуску CI
        • це призводить до повільної роботи члена команди

        На якому кроці зупинитися – сказати складно. Але у будь-якому разі кожен наступний крок описує більш загальну проблему. В цілому всі пункти так чи інакше зводяться до одного конкретного - "уповільнення роботи команди". Тому тут важливо зупинитися десь за 1-2 пункти раніше.

        Зате для кожного наступного більш загального рівня можна запропонувати різні варіанти вирішення проблем:

        • поставити більше CI-агентів для складання та розпаралелити його роботу / складання / дозволити паралельну роботу кількох зборок одночасно
        • поставити сильніше машину для CI
        • викинути частину дій із CI-скрипту, не переписуючи його кардинально
        • повністю переписати CI-скрипт
        • навчити користувача перемикатися між гілками в git, дозволивши йому розпаралелити роботу і не чекати CI
        • зробити простий скрипт для перезапуску failed-сценаріїв 2-3 рази

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

        Крім того, більш загально записане формулювання має більше шансів перетнутися з "мінусом" від іншого учасника. А це добре – значить у нас не 30 різних проблем, а, скажімо, 7-10 (згрупованих). До цього й треба прагнути.

        Дуже важливо при спробі витягти з члена команди загальнішу проблему не задавити його авторитетом і не підкласти свою проблему замість нього. Усі ми люди, всі ми суб'єктивні, і можемо побачити у чужій проблемі зовсім не те, що турбує члена команди, а що турбує нас самих. Вміти залишати свої проблеми осторонь і слухати (і чути) іншу людину, напевно, найважливіше для того, хто збирається працювати в IT з людьми. Але це дуже складно. Нічого страшного, якщо Вас спочатку поправлятимуть і говорити, "ні, це зовсім не те, що мене турбує, мене турбує інше". Чудово, якщо вам це будуть говорити. Набагато гірше, якщо з Вами мовчки погодяться, щоб не сперечатися і швидше закінчити.

        Голосування

        Спочатку вважаємо, що за кожен пункт подано стільки голосів, скільки початкових мінусів було згруповано в нього. Далі я пропоную членам команди проголосувати додатково за 1 або 2 пункти (з згрупованих 7-10), але тільки за ті, в яких немає пунктів, які вони формулювали самі (або в які були переформульовані їхні мінуси).

        В результаті формується відсортований "за голосами" перелік проблем.

        Бліц-етап

        На даному етапі вмикаємо секундомір і пропонуємо по 60 секунд на вирішення кожної проблеми, крім Top3 (у будь-якому порядку). У межах цих 60 секунд можна запропонувати "швидке" вирішення проблеми. Не важливо, наскільки сильно воно вирішує проблему, головне щоб хоч якось вирішувало. Якщо ніхто із членів команди не проти запропонованого рішення, воно записується в action point'и. Якщо проти – рішення відразу ж відкидається без обговорення (час на обговорення не витрачається).

        60 секунд це скоріше орієнтир. На те, що не потрібно витрачати багато часу на бліц-проблеми, які не є найболючішими місцями у процесі.

        Перерва на каву

        Перед перервою на каву остаточно формулюємо top3 проблем, які потрібно обговорити, та пропонуємо членам команди піти покурити/попити/випити/відійти перевірити пошту.

        Обговорення. Action Points

        Отже, ми маємо top3 проблем. Найболючіші, найсерйозніші, найзаважальніші команді. На кожну проблему бодай година обговорення (тому ретро і займає від 3-х годин). Як придумати можливі рішення – не знаю. Проте знаю, що робити з можливими рішеннями.

        По-перше, не треба відкидати рішення, які не вирішують проблеми цілком. Нас цілком влаштують рішення, які вирішують проблему хоча б частково. Хоч на 20%, та полегшують життя команди. Хто знає, може саме цих 20% вистачить, щоб наступного разу проблему не включили до top3?

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

        По-третє, формулювання. Формулювання має бути таким, щоб команда мала мінімальний шанс не виконати пункт.

        Поганий варіант

        Варіант кращий

        Потрібно влаштувати зустріч та обговорити рожевих однорогів

        [Олег] влаштовує зустріч у вівторок о 15 годині з обговорення проблеми харчування рожевих єдинорігів.

        Відповідально підходити до реву pull request'ів

        - (або) при відхиленні pull request'а залишати коментар
        - (або) налаштувати бота, що призначає PR на рев'ю на членів команди
        - (або) додати до CI-скрипту автоматичний лінтер, а всі проблеми в оформленні, які їм не покриваються не вважати проблемами

        заздалегідь формулювати тикети у jira до планування

        [Олег] заведе в outlook щотижневий backlog grooming до планування за участю власника backlog'а, представника аналітиків та solution-архітекторів суміжних систем

        Отримані кроки записуються в action point'и.

        Чому ретро може не допомогти

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

        Ознаками проблем є:

        • Ретроспектива проводиться за півгодини. Це не ретроспектива, це звіт-доповідь команди "як у нас все добре, як здорово та дружно ми живемо, дорогий дідусь ЛенінЯвна ознака того, що захід проводиться для галочки, без тієї користі, яку могло б принести повноцінне ретро.
        • Повторювані у дві-три ретроспективи схожі описи проблем. Команда припускає, що теоретично ці проблеми можна було б спробувати вирішити якимись діями всередині команди. Може бути навіть пропонує action point'и. Але в якийсь момент ці проблеми просто зникають із аналізу, бо команда вже звикла до того, що висловлювати їх марно. Але самі проблеми нікуди не поділися!
        • Якщо таких проблем багато, то в якийсь момент з'являються фрази "надто багато часу витрачається на ретроспективи".Це прямо-таки прямий сигнал про те, що з ретроспективою все погано. І так, без зміни формату ретро далі проводити безглуздо.
        • Невиконані action point'и (при тому що проблема не пішла). Можливо, вони були дуже невдало сформульовані. А можливо, той, хто мав їх виконати, забув/забив/не захотів їх робити.

        Найбільшою проблемою є зрозуміти, що у нас проблеми. Ви можете спокійно дивитися на красиві звіти про ретроспективи в confluence, показувати начальству, а члени команди чомусь не хочуть ходити на них. Моя рекомендація – запрошуйте на ретро раз на півроку когось збоку. Не начальника, а методолога, колегу з паралельної (чи далекої) команди. Можливо запросити навіть його одразу як фасилітатора – спробуйте формат ретроспективи від іншої команди. Нехай її проведе той, хто не звик до формату.