Це стаття Стефані Окерман, яку порадив один із наших тренерів Богдан Онищенко на курсі PSPO.

До речі, тут ви знайдете найближчий тренінг Professional Scrum Product Owner

А стаття — про те, як позбутися “багу” вічного перенесення задач зі спринта в спринт, не передбаченого в скрамі. Ось вам її вільний, доповнений переклад від команди BrainRain.

Як ми знаємо зі Скрам Гайду, метою скраму є створення корисного інкременту до кінця кожного спринту. Такий інкремент називають по-різному: робочий, придатний до використання, готовий до релізу… Готовий. Цілком готовий 😅

То чому ж у командах розповсюджена проблема, коли не встигається зробити готовий інкремент до кінця спринту? Адже не маючи робочого ПЗ або цінності, яку можна використовувати ВЖЕ ЗАРАЗ, ми не маємо і прозорості щодо прогресу й якості. Ми втрачаємо можливість валідувати гіпотези й навчатися.

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

1. Команда не володіє продуктом

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

Характерна ознака цієї “болячки” — накопичення WIP (задачі у стовпчику “В процесі”). Елементи беклогу продукту в беклозі спринту переносяться в наступний спринт. Кожен член команди концентрується на своїй задачі, не озираючись на весь план, всю команду і весь інкремент. Трапляються і проблеми з якістю, та в команді їх не прийнято обговорювати.

До речі, щодо стовпчиків. Скоро якраз тренінг PSK, на якому можна навчитися якнайефективніше об’єднувати скрам із канбаном

2. Брак співпраці

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

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

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

3. Нечітка ціль спринту

Ціль спринту має бути легко виміряти. Тоді команда зможе довкола неї фокусуватися і виявляти гнучкість. Це дуже важливо: ціль має бути легко виміряти.

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

Дайте собі відповідь на кілька питань, щоб дізнатися, чи є ця проблема в вашій команді:

  • Цілі спринту просто немає. Усе, чого від вас чекають, це щоб ви закінчили всі елементи беклогу продукту в беклозі спринту.
  • Розмита ціль спринту. Чи всі члени команди можуть вкінці спринту зі 100% впевненістю сказати, чи вдалося досягти його цілі?
  • Завелика чи збірна ціль спринту.

4. Забагато змін під час спринту

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

То як же збалансувати термінові й несподівані задачі з фактичним виконанням інкременту?

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

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

5. Блоки не усуваються

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

Ось кілька питань, що допоможуть вам виявити розповсюджені блоки:

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

Джерело: Scrum.org