Ідея статті народилась із проблеми, яку я часто зустрічаю під час роботи з різними компаніями: Скрам Майстри не можуть знайти підходи до роботи з Власником Продукту (Product Owner = PO). Ця стаття дасть вам кілька ідей навколо 3-х проблем, чим ви можете бути корисні для PO.

Розгляньмо 3 проблеми, з якими може допомогти Скрам Майстер.

Нерівномірність роботи

Робота, що бере команда - в один спринт беруть, як великі, так і малі задачі, пробуючи “грати в тетріс” у рамках спринту: тобто комбінувати роботу у таким спосіб, щоб в ідеалі всі були зайняті, але все, що взяли, було закінчено. Але чим більше буде варіативність, тим менша ймовірність, що робота в той пазл складеться.

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

• Проведення навчання для команди та PO з декомпозиції. Короткі тренінги, на 1-2 години, можна розробити на прикладі гри Elephant Carpaccio чи подібним їм.
• Комбінуйте навчання з реальним рефайментом беклогу. Проведіть навчання і у той же день зробіть PBR та використовуйте підходи з вашого навчання.
• Цю навичку складно освоїти без регулярної практики, тому рекомендую вам постійно тренуватись у цьому напрямку. Наприклад, самостійно пробуючи декомпозувати ідеї, що є у вашому продукті. Тобто ви берете якийсь функціонал, самостійно декомпозуєте його, дивитесь, як саме можна вашу декомпозицію використовувати, вести інкрементальну розробку, приорітизувати. Обговорюйте декомпозицію з вашим PO, залучайте його та команду до таких дискусій із точки “давайте подумаємо, як ми можемо краще працювати з беклогом”.
• Фокусуйте команду на рівномірній декомпозиції, щоб елементи беклогу, що ви берете в спринт, мали однакову розмірність. Основою такої дискусії можуть бути приклади з Теорії Обмежень.
• Проводьте ретроспективи, що сфокусовані на обговорені того, як робота виконується в спринті, як вона проходить крізь нього, де зависає і чому.
• Фокусуйтесь на цілі спринту, як на інструменті пріоритизації завдань у спринті. Тобто кожен день дивіться, чи ви йдете до цілі, чи ні. Запросіть PO на Daily Scrum в команді, залучайте PO до розмов про ціль та її досягнення.
• Використовуйте онлайн дошки для візуалізації вашого прогресу. Якщо команда чи PO не готові до такого, зробіть таку дошку для себе. Далі ви можете використовувати її для обговорення планів, таким чином ви залучите людей до її використання. Найкращим інструментом для старту буде User Story Mapping. Спробуйте створити її з тими, хто готовий (працюйте з волонтерами). Якщо зовсім туго, залучіть PO і зробіть це з ним. Попросіть його показувати інструмент команді, у такий спосіб ви залучите їх до використання та оновлення інструменту.
• Посилайтеся на візуалізацію при плануванні спринтів та виборі завдань для PBR.

Вотерфольно-ітеративний підхід

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

1. Створення більшої кількості документації, ніж потрібно, втрата на це часу, що фактично зменшує час на розробку
2. Неможливість викинути частину скоупу, якщо ви не встигаєте через сильну інтегрованість рішення на рівні як архітектури, так дизайну бізнес-логіки.
3. Отримання результату вкінці, виявлення найбільших ризиків (інтеграції та поставки) лише на останньому етапі.

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

Що ми можемо запропонувати тут:

• Аналізуйте, скільки ви роботи берете в спринт і скільки закінчуєте, скільки перевалюється зі спринту в спринт;
• Працюйте з PO в напрямку планування лише тої кількості роботи, що ви ісіторично можете виконати (робите 5 задач за спринт, то не беріть більше ніж 5);
• Обговорюйте з PO і командою на PBR тільки той обсяг роботи, що ви можете взяти в наступний спринт, не плануйте на довгий період;
• Оновлюйте роадмап (чи будь-яку іншу візуалізацію прогресу) кожен PBR та планування;
• Аналізуйте виконання цілей спринту з командою і PO, зробіть це ритуалом.

Дезінтеграція Власника продукту й команди

Здебільшого команда бачить власника продукту, як людину, що не є фактичною частиною команди. Проявом цього може бути:

1. Відсутність власника продукту на ретроспективах. Такі ретроспективи, часто, проходять під гаслами “у всіх проблемах винен бізнес”, але дізнатися про це неможливо, бо той самий бізнес не запросили.
2. Підхід “ми”-”вони”, коли команда протиставляє себе умовному Власникові Продукту. Проявом може буди непрозора комунікація про проблеми, або не завчасна. Часто можна побачити динаміку Батьки-Діти, де Власник Продукту поводить себе з командою з батьківського его стану, а вони грають роль неслухняних або бунтівних дітей.

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

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

Що я можу запропонувати вам:

• Зробіть перший крок назустріч PO і запросить його на всі зустрічі.
• Поясніть команді та PO, яку проблему створює його відсутність на зустрічах, особливо на ретро. Будьте відкритими та будьте в позиції “я прошу про допомогу”, а не в позиції “так написано в Скрам Гайді”
• Заплануйте регулярні 1-1 з PO, обговорюйте теми за день до. У такий спосіб ви почнете вибудовувати місток між вами та PO, що дасть змогу відбудувати місток далі з командою.
• Створіть домовленості між усіма ролями, обговоріть очікування.

Сподіваюсь поради будуть вам у пригоді!